Extension and plugin systems are where content-management platforms decide how much they trust the people who can install add-ons — and that decision is a security boundary whether the developers framed it that way or not. CVE-2021-47964, published to the National Vulnerability Database on May 15, 2026, is what happens when the boundary is drawn in the wrong place. It is an authenticated remote code execution vulnerability in Schlix CMS 2.2.6-6, scored 8.8 (HIGH) on CVSS 3.1 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H and classified under CWE-94: Improper Control of Generation of Code — code injection.
The NVD description lays out a remarkably clean attack. An authenticated attacker uploads a crafted ZIP file as an extension through the block manager. Inside that ZIP is a file named packageinfo.inc that contains PHP code. The malicious code does not require a complex trigger: the attacker executes it by navigating to the About tab of the installed extension. In other words, the metadata file that is supposed to describe the extension is instead included and run by the application, turning a descriptive artifact into an execution vector.
The privilege model that quietly failed
The deeper issue is one of misplaced trust. Schlix CMS treats an uploaded extension package as a trusted component — its packageinfo.inc is processed as executable PHP rather than parsed as inert data. That design implicitly assumes that anyone who can upload an extension is authorized to run code on the server. For a platform administrator, that may be a defensible assumption; the admin can usually run code by other means anyway. But the vulnerability carries a Privileges Required value of Low, which means the upload path is reachable by accounts that should not have code-execution authority. The gap between “can upload an extension” and “is allowed to execute arbitrary PHP” is exactly the privilege boundary that this flaw erases.
This is a pattern worth naming, because it recurs across CMS platforms: features built for trusted administrators get exposed, by an overly permissive role model, to less-trusted users, and the original trust assumption silently becomes a vulnerability. The right question for any extension or theme installer is not “does this work for admins?” but “what is the least-privileged role that can reach this, and is it acceptable for that role to run arbitrary code?” When the honest answer is no, the upload must be gated to a higher capability, and the package contents must be treated as data, not code.
Data masquerading as code
The second design error is treating a metadata file as executable. A file called packageinfo.inc sounds like a manifest — a description of the extension's name, version, and author. A well-designed system would parse that as structured data (JSON, XML, or a constrained format) and render its fields. Schlix instead executes it as PHP, which means any value an attacker places inside becomes program logic the moment the About tab is rendered. The CWE-94 classification captures this precisely: the application generates and runs code from input it should have handled as inert.
Once execution is achieved, the impact is total, as the all-High CVSS vector indicates. The attacker runs in the web server's context with access to the database, the file system, and the credentials stored in configuration. From there they can establish persistence, exfiltrate the site's data, and pivot. The triggering action — viewing the About tab — is so mundane that exploitation leaves little obvious trace beyond the extension upload itself.
Mitigation and the design lesson
The references attached to the NVD record include an Exploit-DB entry (49838) and a VulnCheck advisory, and the Schlix download page is linked for version tracking; defenders running 2.2.6-6 should treat the bug as publicly exploitable and move to a patched release. As a compensating control, administrators should restrict extension-upload capability to the smallest possible set of fully trusted accounts and audit the extension directory for packages whose packageinfo.inc contains PHP rather than benign metadata. Any extension installed by a low-privilege account warrants scrutiny.
Trust boundaries in extensible software
Every extensible platform — CMSes, IDEs, browsers, build systems — faces the same fundamental tension: extensions exist to add behavior, which means running third-party code, yet running third-party code is precisely what a security boundary is supposed to control. The mature answer is to make the trust decision explicit and to place it at the highest privilege level. Installing an extension that can run server-side code should be an action reserved for fully trusted administrators, gated behind the strongest capability the platform offers, and ideally accompanied by integrity verification such as signature checks on the package. Schlix CMS instead let the capability leak down to low-privilege roles and processed package metadata as executable code, collapsing the boundary in two directions at once.
The signature-and-provenance angle is increasingly central to how the industry thinks about this class. Software supply-chain attacks have taught defenders that the question is not only “who can install an extension?” but “can we verify the extension is what it claims to be and came from where it claims?” Package managers across ecosystems have moved toward signed artifacts and provenance attestation for exactly this reason. A CMS that accepts an arbitrary uploaded ZIP, executes the metadata file inside it, and asks no questions about origin sits at the opposite end of that maturity spectrum. CVE-2021-47964 is therefore not just a coding bug to patch but a design lesson about how extensibility and trust must be engineered together rather than bolted on.
The durable lesson of CVE-2021-47964 is architectural. Code-execution capabilities should be explicit, gated to the highest privilege, and never granted as a side effect of a file-upload feature aimed at a broader audience. And configuration or metadata bundled with a package must be parsed as data — never included and executed. When a system blurs the line between describing an extension and running it, the description becomes the exploit.