CVERadar
CRITICAL · CVSS 4.0 9.3EPSS 0.76% (p56)Threat level 47

CVE-2026-124004: CVE-2026-124004: XWEB EVO before 5.6.2 contains a hardcoded backdoor password vulnerability that allows una…

Unknown · XWEB EVO · NVD published 2026-11-13 · posted 2026-11-12 · last modified 2026-11-13

CVE-2026-124004 at a glance

CVE-2026-124004 is a critical-severity Hard-coded Credentials vulnerability in XWEB EVO, with a CVSS 4.0 base score of 9.3. NVD published it on 2026-11-13 and classifies the weakness as CWE-798. FIRST EPSS puts the probability of exploitation activity in the next 30 days at 0.76% (percentile 55.9, scored 2026-11-14). NVD does not list a fixed version, so the vendor advisory is the reference for the fix. CVERadar maps 1 MITRE ATT&CK technique across Stealth, Persistence, Privilege Escalation and Initial Access, inferred from the CWE and the description. Its CVERadar threat level is 47/100.

What it is

XWEB EVO before 5.6.2 contains a hardcoded backdoor password vulnerability that allows unauthenticated remote attackers to gain full administrative access to the built-in Administrator account. Attackers can authenticate using the hardcoded credential xwebevonewgeneration in a single request to obtain a complete admin session and full control over the application. This product line reached it's end of service date in March 2026.

WeaknessCWE-798 definition
CVSS vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X (source: VulnCheck)
ATT&CK tacticsInitial Access → Persistence → Privilege Escalation → Stealth

Defend the Chain

The attack chain for CVE-2026-124004 laid across the MITRE ATT&CK Enterprise tactics. Solid cards come from the MITRE CTID KEV mappings; dashed cards are inferred by CVERadar from the CWE or description. Correct defences are real ATT&CK mitigations for that technique.

Threat level 47/100
Defender level 1 · 0 XP
Chain links broken: 0/1

Reconnaissance

Resource Development

Initial Access

Execution

Persistence

Privilege Escalation

Stealth

Defense Impairment

Credential Access

Discovery

Lateral Movement

Collection

Command and Control

Exfiltration

Impact

Pick a red technique card on the board, then choose the defence that stops it.

Defend against T1078.001 Default Accounts Inferred

Inferred from CWE CWE-798

Patches, mitigations and detection

Fixed versions

NVD does not list a fixed version for this CVE. Use the vendor advisory below.

Derived from the NVD CPE configuration (versionEndExcluding / versionEndIncluding). Always confirm with the vendor advisory.

Vendor advisories and patches

No vendor-tagged reference yet; see the full reference list.

MITRE ATT&CK mitigations for this chain

  • M1032 Multi-factor Authentication (for T1078.001) : Implement multi-factor authentication (MFA) for default accounts whenever possible to prevent unauthorized access, even if credentials for these accounts are compromised. MFA adds an additional layer of security that requires more than just a username and password, making it significantly harder for adversaries to expl
  • M1027 Password Policies (for T1078.001) : Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment.

Detection Generic guidance

  • Initial Access: Alert on unusual requests to the affected service (odd paths, oversized payloads, exploit strings) in WAF, reverse-proxy and application logs.
  • Persistence: Look for new files in web roots, new scheduled tasks/services, and new accounts created after the exposure window.
  • Privilege Escalation: Alert on processes gaining SYSTEM/root unexpectedly, and on exploitation crashes of privileged services.

Response checklist Generic guidance

  1. Inventory: find every instance of the affected product and version (include internet-facing and forgotten ones).
  2. Patch or mitigate per the vendor advisory; if you cannot patch, remove internet exposure or apply the vendor workaround.
  3. Assume compromise if the system was exposed before patching: hunt for the indicators in the advisory and review logs back to the disclosure date.
  4. Rotate credentials and secrets stored on or used by the affected system if compromise cannot be ruled out.

Sources