What is the CVSS score of CVE-2025-54322?

CVE-2025-54322 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 15.1%.

Which versions of Xspeeder SXZOS are affected by CVE-2025-54322?

Xspeeder SXZOS, the operating system powering Xspeeder network appliances, contains a critical flaw (CVE-2025-54322, CVSS 9.8) that lets anyone who can reach the device's management interface run…

Is there a public PoC exploit available for CVE-2025-54322?

Yes, a public proof-of-concept exploit is available for CVE-2025-54322. Prioritise patching immediately. EPSS: 15.1%.

How to fix or mitigate CVE-2025-54322?

Within 24 hours, inventory every Xspeeder SXZOS appliance (all builds through 2025-12-26) and immediately remove the management/login interface from any internet-facing exposure - block inbound access at the perimeter firewall and restrict vLogin.py to a small set of trusted administrative IPs over an isolated management VLAN; simultaneously hunt logs for requests to vLogin.py containing suspicious chkid, title, or oIP parameters, especially base64-encoded payloads, and treat any hits as a root-level compromise requiring credential rotation and forensic review. Within 7 days, engage Xspeeder directly for a fixed build and formal advisory statement, since no vendor-released patch is identified at time of analysis and there is currently no exact version to deploy; for any appliance that cannot be isolated, place a compensating control in front of it (reverse proxy, WAF, or IPS rule rejecting malformed chkid values), enforce MFA and strict segmentation so a compromised appliance cannot pivot to core systems, and verify that no management plane remains reachable from untrusted networks. Within 30 days, apply the vendor patch as soon as a fixed build is published and re-verify exposure, or replace/retire the appliance if no patch materializes, and adopt a standing architecture rule that Xspeeder and all other edge appliances are never internet-reachable by default.

Xspeeder SXZOS CVE-2025-54322

CRITICAL

Eval Injection (CWE-95)

2025-12-27 cve@mitre.org

RCE Python Code Injection Sxzos

9.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

9.8 CRITICAL

Network-reachable endpoint evaluates attacker-supplied Python with no authentication or user interaction, yielding root RCE, so AV:N/AC:L/PR:N/UI:N and full C:H/I:H/A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 05, 2026 - 19:40 vuln.today

CVE Published

Dec 27, 2025 - 14:15 nvd

CRITICAL 9.8

DescriptionNVD

Xspeeder SXZOS through 2025-12-26 allows root remote code execution via base64-encoded Python code in the chkid parameter to vLogin.py. The title and oIP parameters are also used.

AnalysisAI

Unauthenticated remote code execution as root in Xspeeder SXZOS lets any attacker who can reach the device's login/management interface run arbitrary Python with full system privileges by supplying base64-encoded code in the chkid parameter of vLogin.py (the title and oIP parameters are also injectable). All SXZOS builds through 2025-12-26 are affected per the wildcard CPE, and exploitation requires no authentication, no user interaction, and no non-default configuration - only network reachability. Publicly available exploit code exists, and the public analysis claims roughly 70,000 exposed hosts, making this a genuine high-priority issue rather than a high-CVSS-but-low-real-risk case; no CISA KEV listing is present in the provided data, and EPSS was not supplied.

Technical ContextAI

The root cause is CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code, i.e. Eval Injection). Xspeeder's SXZOS exposes a login handler, vLogin.py, that takes the chkid parameter (plus title and oIP), base64-decodes its value, and passes the decoded content into Python's dynamic evaluation path rather than treating it as inert data. Because the decoded payload is executed inside the SXZOS web/login service - which runs with root privileges on the appliance - an attacker gains command execution at the highest privilege level without first authenticating, matching the CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8). The CPE string cpe:2.3:o:xspeeder:sxzos:*:*:*:*:*:*:*:* uses a wildcard version, indicating that no fixed build is identified and the entire SXZOS firmware line through the stated date is presumed vulnerable; this is an operating-system-level (firmware) exposure rather than an application-layer component, so standard host-based patching of a package is not applicable - the vendor firmware is the unit of remediation. The Python-code-smuggling vector via base64 is notable because it defeats naive string-pattern filtering of the raw HTTP request and is trivially obfuscated further, so signature-based detection on the literal payload is weak.

RemediationAI

No vendor-released patch was identified in the provided intelligence; the only vendor reference is the general site https://www.xspeeder.com, and the pwn.ai write-up (https://pwn.ai/blog/cve-2025-54322-zeroday-unauthenticated-root-rce-affecting-70-000-hosts) is the sole exploitation source, so administrators should check Xspeeder directly for a firmware update and apply it as soon as one appears. Until then, the highest-value compensating control is to remove the vLogin.py management/login interface from untrusted networks: block inbound access to the device's web/management ports at the perimeter firewall or upstream router, or place the device behind a VPN or IP allowlist - the trade-off is that remote administration must then go through the VPN and any legitimate off-site management path breaks. Do not rely on simply changing default credentials, since exploitation requires no authentication at all. If edge exposure cannot be eliminated, deploy an in-line WAF or IPS in front of the endpoint with rules flagging base64-blob values in chkid/title/oIP and anomalous Python-like tokens after decoding, but treat this as a speed bump - encoding variance and obfuscation can defeat pattern matching, so it must not substitute for isolation. Additionally segment the device from internal networks so a compromise cannot pivot, and monitor egress from the appliance for unexpected outbound connections indicative of post-exploitation command-and-control.