- RCE Security reports that an old CGI script in Imperia CMS let unauthenticated requests run commands on servers where PHP was available. Version 11.8.0 removes the script.
- The flaw needs CGI operation and an enabled script, a setup the vendor says is supported only for compatibility. Features kept for old setups are still attack surface.
- Check whether any Imperia instance runs through CGI, which version it is, and whether the script is reachable from outside.
Some of the riskiest software on a network is software nobody chose to keep. It stays because removing it might break something. A flaw in Imperia CMS, an enterprise content management system, shows how that plays out. Security firm RCE Security reports that a script kept for compatibility let an unauthenticated visitor run commands on a server.
What was found
RCE Security found the problem during a customer penetration test. The firm reports that a visitor with no login can send a crafted request to /cgi-bin/site_active.pl. The request carries the attacker's own template instructions in a parameter called TEMPLATE, and the server treats them as its own. Security researchers call this server-side template injection. With PHP available, it leads to command execution. The firm names version 11.5.4 and below as affected. The write-up carries the identifier CVE-2026-110355.
The vendor, Pirobase Imperia, fixed the issue in version 11.8.0. Its release notes (item ICMS-5602) say only installations run through CGI with the script cgi-bin/site_active.pl enabled are affected. The vendor adds that CGI operation is now supported only for compatibility. In 11.8.0 the script is no longer shipped, and updates remove it from existing installations.
RCE Security describes the product as ISO 27001-certified and lists the Bavarian police among its users. The sources do not say how many installations run through CGI. They also report no attacks in the wild.
How the attack works
The script accepts request parameters without a login. According to RCE Security, it passes them on unless a setting called DEACTIVATE-SITEACTIVE-HTTP is switched on. A filter strips some characters, such as leading slashes, the CGI path, ../ and #. It leaves quotes, parentheses, braces, percent signs and angle brackets in place. Those are the characters the attack needs.
The payload starts with the tag {SITE_ACTIVE}. This steers the request past a safe-filename check, which RCE Security says applies only in another mode. The payload contains no slash, so a later path check does not stop it either.
Next, the template parser wraps the supplied name inside a quoted include directive. The payload closes that directive early. Its PHP code and a special comment land outside it, where they count as ordinary page content.
Why page content became a command
The last step is the instructive one. After rendering, Imperia scans the page for comments of the form postconvert:PLUGIN(args). It turns each into a job. For the PHP job, a plugin called PHPExec starts the server's configured PHP program and connects to it. That program then processes the planted code.
Think of a mailroom that obeys any instruction written inside an envelope. Nobody breaks the lock. The system simply cannot tell content from orders. This is the lesson here: the flaw is less one bad line than a design that lets text from an outsider reach a stage that executes.
Two conditions apply. The server needs a PHP binary, and the script must be reachable. RCE Security says both conditions "do not seem to be unusual." That is the researchers' judgment, not a measured count.
A second fix in the same release
The release notes also list ICMS-4873, found by what the vendor calls an AI-assisted security check. There, editors with access could run server-side code through input fields that lacked escaping. That one is not the unauthenticated flaw. The vendor does not link it to the CVE or say AI found the CGI issue. It says technical details are available on request.
What to ask your team
First, ask whether any Imperia instance runs through CGI, and which version. If it does, ask whether the script is reachable from the internet. RCE Security names 11.5.4 and below. The vendor recommends 11.8.0 for all customers. The sources do not address versions in between, so confirm that with the vendor.
Second, ask where else the organization keeps old modes switched on for compatibility. List them, name an owner for each, and set a date to retire them. Third, ask your web and security teams to confirm that PHP is installed only where it is needed.
RCE Security praised the vendor for a quick fix and for providing a test instance. Its fix does something better than patching one parameter: it deletes the script. The old path was the risk, and removing it ends the exposure.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Pirobase Imperia (vendor of Imperia CMS).
