CVE-2024-7954

What it actually does

This is a critical unauthenticated remote code execution vulnerability in the SPIP porte_plume plugin. A remote attacker can send a crafted HTTP request that causes attacker-controlled PHP code to execute in the context of the SPIP/web server user. Successful exploitation can allow command execution, web shell deployment, credential theft, database access through application configuration files, file modification, and full compromise of the affected SPIP application. The provided affected-product metadata appears inconsistent with the vulnerability description because it references Android Bluetooth components; security teams should validate scanner mappings and prioritize the SPIP porte_plume exposure described by this CVE record.

Why it matters to the business

An exposed vulnerable SPIP site can be taken over without a password, creating a direct path to website defacement, data theft, malware hosting, spam/SEO abuse, lateral movement from the web server, and service disruption. The CVSS score of 9.8, EPSS near 0.90, weaponized exploit maturity, and the age of the issue since publication indicate a high likelihood of real-world exploitation even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an internet-facing SPIP instance running a vulnerable porte_plume version. They then send a specially crafted unauthenticated HTTP request to the vulnerable SPIP endpoint or plugin functionality that processes attacker-controlled input. The vulnerable code path evaluates or interprets the supplied content in a way that results in PHP execution as the SPIP/web server user. After gaining execution, the attacker typically runs reconnaissance commands, reads SPIP configuration files for database credentials, writes a PHP web shell into a web-accessible directory, modifies site content, exfiltrates data, or uses the server as a foothold for further attacks.

How to fix it

Upgrade SPIP to a fixed release immediately: SPIP 4.2.13 or later for the 4.2 branch, SPIP 4.1.16 or later for the 4.1 branch, or 4.3.0-alpha2 / 4.30-alpha2 or later where applicable to the deployment track. Update the porte_plume plugin and all bundled SPIP components from trusted upstream sources. If immediate upgrade is not possible, restrict public access to SPIP administrative and plugin endpoints, place the site behind a WAF with rules for suspicious PHP payloads and porte_plume exploit patterns, disable unnecessary plugins, and ensure the web server user cannot write executable PHP into upload/cache directories. Because the supplied package list references Android Bluetooth fixed in the 2022-11-01 Android security level, organizations receiving Android findings under this identifier should validate the vulnerability mapping and apply the November 2022 Android security patches where relevant, but should not treat that as remediation for the SPIP porte_plume issue.

How to confirm the fix worked

Confirm the running SPIP version is at or above the fixed branch version and that the updated porte_plume plugin files are deployed on all web nodes. Verify no vulnerable copy remains in backup directories, alternate document roots, containers, staging sites, or old virtual hosts. From an external perspective, confirm unauthenticated requests to porte_plume-related preview/action endpoints no longer result in server-side PHP execution and return only expected application behavior. Review file permissions to ensure upload, cache, IMG, local, and tmp directories cannot execute PHP. Validate scanner results carefully because the supplied affected-product mapping is inconsistent with the SPIP vulnerability description.

Typical attack path

1. Scan the internet or target estate for SPIP installations and exposed SPIP endpoints.
2. Fingerprint the SPIP version, installed plugins, or porte_plume behavior to identify vulnerable instances.
3. Send a crafted unauthenticated HTTP request that triggers the porte_plume arbitrary PHP execution flaw.
4. Execute a simple command or PHP payload to confirm code execution.
5. Read application configuration files and environment data for credentials and secrets.
6. Deploy a persistent PHP web shell or secondary payload in a writable web directory.
7. Use the compromised SPIP server to steal data, alter website content, pivot internally, or maintain persistence.

How to detect it

Review web server access logs, reverse proxy logs, WAF events, PHP-FPM logs, application logs, and EDR telemetry on SPIP servers. Look for unauthenticated requests referencing porte_plume functionality, especially POST requests with encoded payloads, PHP tags, command-execution function names, or unusual parameters. Investigate HTTP 200/500 responses around suspicious requests, followed by new PHP files, outbound network connections, spawned shell processes, or database access outside normal patterns. On the host, inspect web-writable directories such as IMG, local, tmp, cache, and plugin paths for recently modified PHP files. Review process execution for the web server user launching shells, interpreters, download tools, or network utilities. If compromise is suspected, collect filesystem timelines, access logs, PHP error logs, SPIP configuration files, and database audit logs before cleanup.

• action=porte_plume_previsu
• spip.php?action=porte_plume_previsu
• porte_plume_previsu
• /ecrire/?exec=porte_plume
• porte_plume
• <?php
• base64_decode(
• eval(
• assert(
• system(
• shell_exec(
• passthru(
• proc_open(
• popen(
• phpinfo(
• cmd=
• /IMG/
• /local/
• /tmp/
• /cache/
• c99.php
• r57.php
• wso.php
• b374k.php

What your security team should do

• Treat internet-facing SPIP instances as urgent patch targets due to weaponized exploitation and very high EPSS likelihood.
• Inventory all SPIP deployments, including staging, legacy, containerized, and partner-managed sites.
• Upgrade to SPIP 4.2.13, 4.1.16, 4.3.0-alpha2/4.30-alpha2, or later as appropriate for the deployed branch.
• Hunt for exploitation before and after patching, especially suspicious requests involving porte_plume endpoints and PHP execution markers.
• Search web roots and writable directories for newly created or modified PHP files, especially web shells under IMG, local, tmp, cache, or plugin directories.
• Rotate SPIP database credentials, administrator passwords, API keys, and any secrets stored on the server if exploitation is suspected.
• Apply WAF detections for PHP payloads, command-execution functions, encoded payloads, and suspicious unauthenticated POSTs to SPIP endpoints.
• Validate vulnerability-management mappings where this CVE is reported against Android Bluetooth components, because the provided metadata conflicts with the SPIP vulnerability description.