← Back to Feed CACHED · 2026-10-24 04:53:59 · CACHE_KEY CVE-2026-110355
CVE-2026-110355 · CWE-1336 · Disclosed 2026-10-20

Imperia CMS SiteActive TEMPLATE unauthenticated SSTI remote code execution via PHPExec postconverter

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left a loaded function in the vending machine's coin slot, and any passerby can trigger it

CVE-2026-110355 is an unauthenticated Server-Side Template Injection (SSTI) leading to Remote Code Execution in Imperia CMS ≤ 11.7.2, a niche enterprise content management system built in Perl and heavily deployed across German government agencies, universities, and police portals. The flaw lives in the /cgi-bin/site_active.pl CGI endpoint, which accepts a TEMPLATE parameter without authentication. An attacker crafts a single GET request that (1) bypasses the input sanitizer by using a {SITE_ACTIVE} prefix to disable the is_safe_docname path check, (2) breaks out of the template engine's include directive by injecting a closing ')%}, and (3) injects a <!--postconvert:PHPExec()--> HTML comment that pipes the rendered page through the PHP binary for arbitrary code execution. The researcher Julien Ahrens of RCE Security published a full proof-of-concept payload on October 20, 2026. Patched in version 11.8.0.

No vendor CVSS score has been published for this CVE. The real severity hinges on one non-obvious prerequisite: the PHP binary must be installed on the server for the PHPExec postconverter to fire. Imperia CMS itself is Perl-based, so PHP is *not* a guaranteed dependency — but in practice, most enterprise Linux web servers carry PHP as a standard package or dependency of adjacent tools. With PHP present, the chain is a textbook unauthenticated-RCE-via-GET — as lethal as it gets for a web application. Without PHP, the chain terminates silently. This single condition is what separates a CRITICAL rating from a HIGH. Imperia's own security documentation acknowledges that SiteActive templates should be protected from web access, but the default configuration leaves the endpoint exposed — hardening is opt-in, not opt-out.

"Unauth RCE via a single GET to site_active.pl; PHP on the box is the only gate"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the SiteActive CGI endpoint

The attacker sends an unauthenticated HTTP GET request to /cgi-bin/site_active.pl on the target Imperia CMS instance. This endpoint is internet-facing by design — it serves maintenance/status pages to public visitors. No credentials, cookies, or tokens are required. The only gate is whether the DEACTIVATE-SITEACTIVE-HTTP configuration flag is set, which it is *not* by default.
Conditions required:
  • Target runs Imperia CMS ≤ 11.7.2
  • CGI execution enabled on the web server (default for Imperia)
  • DEACTIVATE-SITEACTIVE-HTTP is not set (default)
Where this breaks in practice:
  • Imperia CMS has a very small installed base (~700 live sites globally, ~93% in Germany)
  • The site must be reachable from the attacker's network — but these are public-facing CMS instances by nature
Detection/coverage: Imperia CMS fingerprinting via HTTP headers or /cgi-bin/site_active.pl path probing; Shodan/FOFA dorks for site_active.pl or Imperia-specific response headers
STEP 02

Bypass input sanitization and path safety checks

The TEMPLATE parameter value begins with {SITE_ACTIVE}, which triggers special handling in Imperia::SiteActive. This prefix sets in_docroot to 0, causing the is_safe_docname security check to be skipped entirely (it only fires when in_docroot == 1). The request sanitizer strips leading slashes, ../, CGI-BIN paths, and # characters — but critically preserves quotes, parentheses, braces, percent signs, and angle brackets, all of which are essential to the SSTI payload.
Conditions required:
  • Step 1 conditions met
  • Attacker understands the sanitizer's allowlist gaps (publicly documented in the PoC)
Where this breaks in practice:
  • The bypass is deterministic and requires no brute-forcing or timing — once the PoC is known, it works every time
Detection/coverage: WAF rules matching {SITE_ACTIVE} or postconvert:PHPExec in query strings; IDS signatures for URL-encoded template injection tokens (%25}, %3f)
STEP 03

Inject SSTI payload into template include

The Imperia view parser (Imperia::View::Parser) inserts the supplied TEMPLATE filename into a single-quoted include directive: {% ##include ('$what')%}. The payload contains X')%} which closes the include directive prematurely, allowing the attacker to inject arbitrary template content — including raw PHP code and HTML comments — into the rendered page output.
Conditions required:
  • Steps 1-2 complete
  • The template parser processes the TEMPLATE parameter as expected (standard behavior in all affected versions)
Where this breaks in practice:
  • None — this is deterministic behavior in the parser
Detection/coverage: Application-layer logging of TEMPLATE parameter values containing ')%} sequences
STEP 04

Trigger PHPExec postconverter for RCE

The rendered page passes through Imperia's conversion pipeline (Imperia::Template::Convert), which scans for <!--postconvert:PLUGIN(args)--> HTML comments. The injected <!--postconvert:PHPExec()--> comment activates the Dynamic/Convert/PHPExec.pm plugin, which pipes the entire page content — now containing attacker-controlled <?php system('id');?> — through the PHP binary for execution. The attacker achieves arbitrary command execution as the web server user.
Conditions required:
  • Steps 1-3 complete
  • PHP binary must be installed and accessible on the target server
Where this breaks in practice:
  • This is the key friction point. Imperia CMS is Perl-based; PHP is not a hard dependency. However, most enterprise Linux servers have PHP installed as a standard package or dependency of other applications. Estimated 60-80% of deployments will have PHP available.
  • Even without PHP, the SSTI itself succeeds — the chain only breaks at the code execution step
Detection/coverage: Process monitoring for php spawned by the Imperia web process; file integrity monitoring on webroot; command execution artifacts (e.g., /tmp file drops, reverse shells)
03 · Compensating Control

1
HIGH 8.1→LOW 2.0
SEVERITY REDUCED
Block access to /cgi-bin/site_active.pl at the reverse proxy or WAF — Add an immediate deny rule for the /cgi-bin/site_active.pl path on your reverse proxy (nginx, Apache, HAProxy) or WAF. This completely breaks the attack chain at step 1 — the attacker cannot reach the vulnerable endpoint. If SiteActive functionality is needed for maintenance pages, restrict access to internal IPs only. Deploy within 30 days per the noisgate mitigation SLA for HIGH-severity findings, though given the public PoC, deploying within 7 days is strongly recommended.
2
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCED
Set DEACTIVATE-SITEACTIVE-HTTP in Imperia configuration — In system.conf or config.conf, set DEACTIVATE-SITEACTIVE-HTTP = 1 to disable HTTP access to the SiteActive module entirely. This is the vendor-recommended hardening control and eliminates the attack surface at the application layer. This is a complementary control to the reverse proxy block — defense in depth. Deploy within 30 days per the noisgate mitigation SLA.
3
HIGH 8.1→MEDIUM 5.5
SEVERITY REDUCED
Remove or restrict the PHP binary on Imperia CMS servers — If PHP is not required for Imperia CMS operation (it shouldn't be — Imperia is Perl-based), uninstall the php package or restrict the PHP binary's execute permissions. This breaks the attack chain at step 4 — the PHPExec postconverter cannot invoke PHP. Verify with which php and php -v on the target server. Deploy within 30 days.
4
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCED
Upgrade to Imperia CMS 11.8.0 — Apply the vendor patch (11.8.0+) which addresses the SSTI chain. This is the definitive remediation. Coordinate with pirobase imperia GmbH for upgrade path. Deploy within 180 days per the noisgate remediation SLA for HIGH-severity findings.
What doesn't work
  • Network segmentation alone — Imperia CMS instances are internet-facing by design (they serve public websites). Putting them behind a firewall defeats their purpose. The control must be path-specific, not host-specific.
  • Generic SSTI WAF signatures — The Imperia template syntax ({%, ##include, postconvert:) is non-standard and unlikely to be covered by default SSTI rule sets (which target Jinja2, Twig, Freemarker, etc.). Custom rules are required.
  • Upgrading PHP — The vulnerability is not in PHP itself; PHP is merely the execution vehicle. Any PHP version will execute the injected code.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo evidence found. Not listed in CISA KEV. No GreyNoise scanning activity identified for this CVE as of 2026-10-24. No known campaigns.
Proof-of-ConceptPublic and weaponized. Full PoC payload published by Julien Ahrens (RCE Security) on 2026-10-20. Single GET request — trivially reproducible. No GitHub exploit repos found yet on pocindex.io or in CVE-2026-PoC aggregator repos, but the blog post itself contains the complete curl-ready payload.
EPSS ScoreNot yet scored by FIRST EPSS (CVE too recent — disclosed 2026-10-20).
KEV StatusNot listed in CISA KEV as of 2026-10-24.
CVSS Vector (noisgate-assessed)CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1. AC:H reflects the PHP binary dependency — without it the chain terminates. All other metrics are worst-case: network-reachable, no auth, no interaction, full CIA impact.
Affected VersionsImperia CMS ≤ 11.7.2 (includes all version 11.x releases through 11.7.2, and likely earlier major versions with the SiteActive module). Per W3Techs, version 11 represents ~33% and version 10 represents ~58% of the ~700 live installations.
Fixed VersionImperia CMS 11.8.0 — vendor (pirobase imperia GmbH) responded promptly and provided a test instance for verification.
Exposure / Installed Base~700 live sites globally per WebTechSurvey, with 93% in Germany (656 .de domains). Deployments concentrated in German government agencies (Bayern.de, DAAD, Bavarian Police, University of Münster, City of Nuremberg). Niche enterprise CMS — ranks #348 in CMS category with <0.1% market share.
Disclosure Date2026-10-20 (public writeup by Julien Ahrens on rcesecurity.com).
Researcher / OrgJulien Ahrens, RCE Security — prolific researcher with 39+ published PoCs across 18+ CVEs. Coordinated disclosure with pirobase imperia GmbH.

Sources.

  1. RCE Security — Full Advisory & PoC
  2. RCE Security — Research Index
  3. Imperia CMS Security Documentation
  4. W3Techs — Imperia CMS Market Share
  5. WebTechSurvey — Imperia CMS Live Sites
  6. Vulners — PT-2026-110355
  7. pirobase imperia GmbH — Vendor
  8. Imperia CMS Version List
05 · The Call

Final Verdict
= UNCHANGED to HIGH (8.1/10)

Why this verdict

  • Unauthenticated RCE via single GET request: The attack requires zero credentials, zero user interaction, and delivers full command execution. This is the most dangerous class of web vulnerability. Starting baseline for an unauth-RCE-in-default-config web application: CRITICAL (9.8).
  • PHP binary dependency — downward adjustment (-1.0 to -1.5): The chain terminates without the PHP binary. Imperia is Perl-based; PHP is not a required dependency. Estimated 60-80% of enterprise Linux servers have PHP installed, so this is a *probabilistic* gate, not a hard block. This single condition moves the score from AC:L (9.8) to AC:H (8.1).
  • Public PoC with trivial weaponization — no upward recovery needed: The RCE Security blog post includes a complete curl-ready payload. No exploit development work is needed. Friction from PoC unavailability: zero.
  • Default configuration is vulnerable — no upward recovery needed: The DEACTIVATE-SITEACTIVE-HTTP flag is unset by default. Imperia's own security docs treat hardening SiteActive access as an opt-in recommendation, not a default. Most deployments are exposed.
  • Role multiplier: Imperia CMS occupies a *typical role* (b) as a public-facing content management server. It is not a canonical high-value infrastructure component (not an IdP, hypervisor, PAM, backup, CA, CI/CD, or network edge appliance). The blast radius of a compromise is host-level — the attacker gains code execution as the web server user, which enables webshell persistence, site defacement, database exfiltration, and potential lateral movement into the internal network. For government deployments (Bavarian Police, DAAD, federal state portals), the reputational and intelligence impact is elevated, but the technical blast radius remains host-to-network, not domain/fleet/supply-chain. No floor override triggered.
  • Small installed base — context, not adjustment: Only ~700 live sites globally. This does not change the per-vulnerability severity for affected organizations, but it means most enterprises will not have Imperia CMS in their asset inventory at all.

Why not higher?

A CRITICAL (≥9.0) rating would require the attack chain to succeed deterministically against all default installations. The PHP binary dependency introduces a configuration prerequisite that is beyond the attacker's control and absent in a meaningful fraction (est. 20-40%) of Imperia CMS deployments. Additionally, Imperia CMS is not a canonical high-value infrastructure component — compromise yields host-level, not fleet-level or domain-level impact. No floor override applies.

Why not lower?

Dropping below HIGH would ignore the fact that this is an *unauthenticated* RCE with a *public PoC* that requires a single GET request against a *default-configuration* endpoint. Where PHP is present, there is effectively zero friction. The targets are disproportionately government agencies. Even with the niche installed base, any organization running Imperia CMS faces a direct, immediate, internet-facing RCE risk.

06 · Verification

Crowdsourced verification payload.

Run this script from an auditor workstation (not the target) with network access to the Imperia CMS instance. Invoke as: bash check_cve_2026_110355.sh https://target.example.de. No special privileges required — it sends only safe, non-exploitative HTTP requests.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-110355 Imperia CMS SiteActive SSTI Pre-Auth RCE Check
# Safe, non-exploitative detection only — no payload execution.
# Usage: bash check_cve_2026_110355.sh <base_url>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

BASE_URL="${1:-}"
if [[ -z "$BASE_URL" ]]; then
  echo "Usage: $0 <base_url>  (e.g. https://target.example.de)"
  exit 2
fi

# Strip trailing slash
BASE_URL="${BASE_URL%/}"
ENDPOINT="${BASE_URL}/cgi-bin/site_active.pl"

echo "[*] CVE-2026-110355 — Imperia CMS SiteActive SSTI Check"
echo "[*] Target: ${BASE_URL}"
echo ""

# Step 1: Check if the SiteActive endpoint is reachable
echo "[*] Step 1: Probing SiteActive endpoint..."
HTTP_CODE=$(curl -sk -o /dev/null -w '%{http_code}' --max-time 10 "${ENDPOINT}" 2>/dev/null || echo "000")

if [[ "$HTTP_CODE" == "000" ]]; then
  echo "[-] Connection failed or timed out."
  echo "UNKNOWN — cannot reach ${ENDPOINT}"
  exit 2
elif [[ "$HTTP_CODE" == "403" || "$HTTP_CODE" == "404" || "$HTTP_CODE" == "405" ]]; then
  echo "[+] Endpoint returned HTTP ${HTTP_CODE} — SiteActive appears blocked or absent."
  echo "PATCHED — SiteActive endpoint not accessible (HTTP ${HTTP_CODE})"
  exit 1
elif [[ "$HTTP_CODE" =~ ^(200|302|301|500)$ ]]; then
  echo "[!] Endpoint returned HTTP ${HTTP_CODE} — SiteActive is reachable."
else
  echo "[?] Unexpected HTTP ${HTTP_CODE} from endpoint."
  echo "UNKNOWN — unexpected response"
  exit 2
fi

# Step 2: Check for Imperia CMS fingerprints in the response
echo "[*] Step 2: Checking for Imperia CMS fingerprints..."
RESPONSE=$(curl -sk --max-time 10 -D - "${ENDPOINT}" 2>/dev/null || true)

IS_IMPERIA=0
if echo "$RESPONSE" | grep -qi 'imperia'; then
  IS_IMPERIA=1
  echo "[!] Imperia CMS fingerprint detected in response."
elif echo "$RESPONSE" | grep -qi 'site.active\|siteactive\|SITE_ACTIVE'; then
  IS_IMPERIA=1
  echo "[!] SiteActive module fingerprint detected."
else
  echo "[?] No clear Imperia CMS fingerprint — endpoint may not be Imperia."
fi

# Step 3: Check with a safe TEMPLATE parameter (no exploit)
echo "[*] Step 3: Testing TEMPLATE parameter handling (safe probe)..."
SAFE_RESP=$(curl -sk -o /dev/null -w '%{http_code}' --max-time 10 \
  "${ENDPOINT}?TEMPLATE={SITE_ACTIVE}noisgate_safe_probe_test" 2>/dev/null || echo "000")

if [[ "$SAFE_RESP" == "200" || "$SAFE_RESP" == "500" ]]; then
  echo "[!] TEMPLATE parameter with {SITE_ACTIVE} prefix accepted (HTTP ${SAFE_RESP})."
  echo "[!] The SiteActive endpoint processes TEMPLATE parameters — exploitation likely possible."
  echo ""
  echo "VULNERABLE — Imperia CMS SiteActive endpoint is reachable and processes TEMPLATE parameter."
  echo "  Affected: Imperia CMS <= 11.7.2"
  echo "  Fix: Upgrade to 11.8.0+ or block /cgi-bin/site_active.pl"
  exit 0
elif [[ "$SAFE_RESP" == "403" ]]; then
  echo "[+] TEMPLATE parameter request blocked (HTTP 403)."
  echo "PATCHED — TEMPLATE parameter requests are denied."
  exit 1
else
  if [[ $IS_IMPERIA -eq 1 ]]; then
    echo "[?] TEMPLATE probe returned HTTP ${SAFE_RESP} on confirmed Imperia instance."
    echo "UNKNOWN — Imperia detected but TEMPLATE handling unclear. Manual review recommended."
    exit 2
  else
    echo "[?] TEMPLATE probe returned HTTP ${SAFE_RESP} — may not be Imperia CMS."
    echo "UNKNOWN — could not confirm Imperia CMS or vulnerability status."
    exit 2
  fi
fi