Debian DSA-6435-1: SPIP Unauthenticated RCE, SQL Injection, and SSRF — Detection and Remediation Guide

Debian's security team has released DSA-6435-1, addressing multiple vulnerabilities in SPIP — the open-source content management system written in PHP and used extensively by French-language publishing sites, associations, and public-sector organizations. The advisory covers an unauthenticated remote code execution vulnerability, SQL injection risks, and server-side request forgery (SSRF) weaknesses. If you run SPIP anywhere in your environment — particularly internet-facing instances — treat this as an emergency patch, not a routine maintenance window.

Introduction: Why This Advisory Demands Immediate Action

The combination in this advisory is the worst possible pairing from a defender's standpoint:

• Unauthenticated RCE means no credentials, no session, no foothold required. An attacker with network reachability to the SPIP web root can execute arbitrary code in the context of the web server user (typically www-data).
• SQL injection against a CMS database means full exfiltration of content, user credentials (including editor and administrator accounts), and configuration data — and in many configurations, escalation to code execution via INTO OUTFILE or stacked queries.
• SSRF turns the vulnerable server into a pivot point: attackers can reach internal services, cloud metadata endpoints (169.254.169.254), and otherwise unreachable backend infrastructure from the outside.

SPIP powers a substantial installed base, particularly across francophone media, academia, and government-adjacent publishing. These are precisely the environments where a single compromised CMS instance becomes a beachhead for broader intrusion, defacement, or data theft. Debian has fixed the packages; the only correct response is to upgrade now.

Technical Analysis

Affected Products and Platforms

• Software: SPIP CMS, as packaged by Debian (spip package)
• Distribution: Debian stable and related releases covered by the Debian Security Tracker; users should consult DSA-6435-1 and the Debian Security Tracker for the exact fixed version for their release
• Exposure model: Any SPIP instance reachable over HTTP/HTTPS is a candidate target. Unauthenticated attack surface means no login or prior access is required

How the Attack Chain Works (Defender's Perspective)

1. Unauthenticated code execution. The attacker crafts malicious HTTP requests against SPIP's public-facing PHP entry points — typically spip.php, ecrire/, or public squelette/form processing endpoints — and abuses the vulnerable code path to achieve arbitrary PHP or command execution. Post-exploitation, expect:

• The web server process (apache2, php-fpm) spawning unexpected child processes (sh, bash, curl, wget)
• Webshell deployment into writable SPIP directories (IMG/, tmp/, local/, or plugin paths)
• Outbound connections to attacker-controlled infrastructure for payload retrieval or C2

2. SQL injection. Malicious input reaches SPIP's SQL query construction without adequate sanitization. Observable artifacts include anomalous HTTP requests containing SQL metacharacters (', --, UNION SELECT, sleep(, benchmark() against SPIP endpoints, followed by database error messages or time-delayed responses. Impact: credential theft from the spip_auteurs table, content manipulation, and potential file write via the database user.

3. SSRF. SPIP's remote-fetch functionality (used for syndication, document retrieval, and URL-based features) can be coerced into requesting arbitrary internal URLs. Observable artifacts: outbound connections from the web server to RFC1918 addresses, loopback, link-local metadata IPs, or internal service ports that the CMS has no business contacting.

Exploitation Status

Debian security advisories are typically issued for vulnerabilities with known, credible risk, and the co-occurrence of an unauthenticated RCE class bug with SQL injection and SSRF makes mass scanning and opportunistic exploitation a realistic near-term outcome. Web CMS vulnerabilities of this class are historically weaponized within days of disclosure — automated scanners fingerprint SPIP installations via spip.php, generator meta tags, and /ecrire/ paths. Defenders should assume scanning activity is underway and hunt accordingly.

Detection & Response

This is a technical threat. The detections below target the observable behaviors of exploitation: anomalous requests to SPIP endpoints, webshell deployment and execution, post-exploitation process trees, and SSRF-style outbound connections.

Sigma Rules

---
title: SPIP Webshell Execution via Web Server Process Spawn
id: 3f8b1d2a-9c4e-4a7b-b5d1-2e6f8a0c4d7e
status: experimental
description: Detects the web server or PHP-FPM process spawning shell interpreters or download tools, consistent with post-exploitation of the SPIP unauthenticated RCE fixed in Debian DSA-6435-1.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6435-1-spip
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059.004
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/apache2'
      - '/php-fpm'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate SPIP plugins invoking system utilities (rare; validate against change window)
  - Monitoring or backup scripts running under the web server context
level: high
---
title: Suspicious File Write into SPIP Web Directories
id: 7c1e5a90-3b2f-4d68-9a14-5f0b8c6e2d91
status: experimental
description: Detects creation of PHP files in SPIP upload and temp directories (IMG/, tmp/, local/) by the web server user, a strong indicator of webshell deployment following RCE exploitation.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6435-1-spip
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/IMG/'
      - '/tmp/'
      - '/local/'
      - '/plugins/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate SPIP plugin installation or update activity — correlate with change management records
level: high
---
title: SSRF Indicators - Web Server Outbound Connection to Internal or Metadata Addresses
id: 9d4a2f67-8e1c-4b5a-a392-6c7d0e1f8b34
status: experimental
description: Detects outbound connections from web server/PHP processes to loopback, link-local metadata, or RFC1918 destinations consistent with SSRF exploitation of SPIP's remote-fetch features.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6435-1-spip
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: linux
detection:
  selection_src:
    Image|endswith:
      - '/apache2'
      - '/php-fpm'
  selection_dst:
    DestinationIp|startswith:
      - '127.'
      - '169.254.'
      - '10.'
      - '192.168.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.2'
      - '172.30.'
      - '172.31.'
  condition: selection_src and selection_dst
falsepositives:
  - SPIP syndication features fetching known internal RSS feeds — allowlist approved destinations
  - Reverse proxy or health-check architectures where the web tier legitimately calls internal APIs
level: medium

KQL (Microsoft Sentinel / Defender)

The following hunts assume Linux web server telemetry is ingested into Sentinel via Syslog (auditd execve) or CEF from a WAF/reverse proxy. The first query targets anomalous HTTP requests against SPIP endpoints carrying SQLi or probing payloads; the second targets the post-exploitation process tree.

// Hunt 1: Suspicious HTTP requests to SPIP endpoints (WAF / proxy / Apache access logs via CommonSecurityLog or custom table)
let lookback = 7d;
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL has_any ("spip.php", "/ecrire/", "/prive/", "spip_loader")
| where RequestURL has_any ("'", "--", "union", "select", "sleep(", "benchmark(", "../", "%2e%2e", "eval(", "base64_decode", "php://input")
   or Message has_any ("union select", "sleep(", "benchmark(")
| summarize RequestCount = count(), DistinctSources = dcount(SourceIP) by SourceIP, RequestURL, RequestMethod
| order by RequestCount desc;
// Hunt 2: Web server spawning shells or download tools post-exploitation (auditd execve via Syslog)
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has_all ("type=EXECVE", "exe=")
| extend ExePath = extract(@'exe="([^"]+)"', 1, SyslogMessage)
| extend CmdLine = extract(@'argc=.*', 0, SyslogMessage)
| where ExePath has_any ("/sh", "/bash", "/dash", "/curl", "/wget", "/nc", "/python", "/perl")
| where SyslogMessage has_any ("www-data", "apache", "php-fpm", "nginx")
| project TimeGenerated, Computer, ExePath, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

This artifact hunts for recently written PHP files in SPIP's writable directories — the classic webshell landing zone after CMS RCE.

-- Hunt for recently created PHP files in SPIP writable directories (potential webshells)
LET search_dirs = (
  SELECT FullPath, Mtime, Size
  FROM glob(globs=['/var/www/**/IMG/**/*.php', '/var/www/**/tmp/**/*.php', '/var/www/**/local/**/*.php'])
)
SELECT FullPath, Mtime, Size,
       read_file(filename=FullPath, length=512) AS FileHeader
FROM search_dirs
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Remediation Script (Bash)

Run on Debian hosts to identify the installed SPIP package, apply the security update, verify the fixed version, and perform a quick webshell sweep.

#!/bin/bash
# SPIP DSA-6435-1 remediation and verification script
set -euo pipefail

echo "=== [1] Current SPIP package status ==="
if dpkg -l spip 2>/dev/null | grep -q '^ii'; then
    dpkg -l spip | tail -n +6
else
    echo "spip package not installed via apt. Check for manual/source installations under /var/www and /srv."
    find /var/www /srv -maxdepth 3 -iname "spip.php" 2>/dev/null || echo "No manual SPIP installs found in common paths."
fi

echo "=== [2] Applying Debian security update ==="
apt-get update
apt-get install -y --only-upgrade spip

echo "=== [3] Post-update version verification ==="
apt-cache policy spip
echo "Confirm the installed version matches the fixed version listed in DSA-6435-1."

echo "=== [4] Webshell sweep: recently modified PHP files in SPIP writable dirs ==="
find /var/www -path '*/IMG/*' -o -path '*/tmp/*' -o -path '*/local/*' 2>/dev/null \
    | grep -E '\.(php|phtml|phar)$' \
    | while read -r f; do
        if [ "$(find "$f" -mtime -14 2>/dev/null)" ]; then
            echo "RECENT: $f ($(stat -c '%y %U' "$f"))"
        fi
      done

echo "=== [5] Check web server process tree for anomalous children ==="
for pid in $(pgrep -f 'apache2|php-fpm'); do
    children=$(pgrep -P "$pid" -a 2>/dev/null | grep -E 'sh|bash|curl|wget|nc |python|perl' || true)
    [ -n "$children" ] && echo "ALERT pid $pid spawned: $children"
done

echo "=== Done. Review findings above; isolate host if webshells or anomalous processes are found. ==="

Remediation

1. Patch immediately. Run apt-get update && apt-get install --only-upgrade spip on all Debian hosts running SPIP. Confirm the installed version against the fixed package version listed in DSA-6435-1 and the Debian Security Tracker entry for spip. The full advisory is mirrored at LinuxSecurity.
2. Inventory every SPIP instance. SPIP is frequently deployed standalone from upstream source rather than via apt — search web roots for spip.php, spip_loader.php, and /ecrire/ directories. Any manually installed instance must be upgraded to the corresponding fixed upstream SPIP release, not left at the old version because apt shows nothing.
3. Assume pre-patch exposure and hunt. Because the RCE is unauthenticated, patching alone does not clear compromise. Run the webshell sweep and process-tree checks above on every affected host. Review web access logs for the 30 days preceding the patch for probing of SPIP endpoints with SQLi patterns or anomalous POST bodies.
4. Constrain SSRF surface. Where architecture permits, apply egress filtering on the web tier: deny outbound connections from the web server to RFC1918, loopback, and 169.254.169.254 (cloud metadata). If the instance is cloud-hosted, enforce IMDSv2 (AWS) or equivalent metadata protection.
5. Reduce attack surface. Restrict access to /ecrire/ (the SPIP administrative back office) via web server ACLs or IP allowlisting. Ensure SPIP's writable directories (IMG/, tmp/, local/) are configured to deny PHP execution at the web server layer — this single hardening step neuters the most common webshell deployment pattern even if code execution recurs.
6. Rotate credentials on suspected-compromise hosts. If hunting surfaces webshells, anomalous processes, or suspicious SQLi requests, rotate all SPIP author/admin credentials, database credentials in config/connect.php, and any secrets reachable from the host — then rebuild from known-good media rather than cleaning in place.
7. Add detection coverage. Deploy the Sigma rules above to your Linux web fleet and validate the KQL hunts against at least 7 days of historical telemetry. SPIP's installed base makes it a recurring target; these detections remain valuable beyond this advisory.

Bottom Line

An unauthenticated RCE bundled with SQL injection and SSRF in a widely deployed CMS is the definition of a patch-now event. Debian has done its part with DSA-6435-1. The defender's job is threefold: patch every instance (including the ones apt doesn't know about), hunt for exploitation that may have preceded the patch, and harden the web tier so the next CMS advisory is an inconvenience rather than an incident.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub