What is the CVSS score of CVE-2026-46493?

CVE-2026-46493 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Which versions of HAX CMS are affected by CVE-2026-46493?

HAX CMS (haxcms-php) versions prior to 26.0.1 use weak cryptographic salt generation that allows unauthenticated remote attackers to predict authentication credentials, creating an account takeover…. A patch is available.

How to fix or mitigate CVE-2026-46493?

24 hours: Identify all instances of haxcms-php and their versions across production and non-production environments. 7 days: Implement network-level restrictions to limit access to HAX CMS installation and authentication endpoints; evaluate upgrade feasibility to version 26.0.1 if available or apply compensating controls listed below. 30 days: Complete remediation through upgrade to patched version or establish persistent compensating control framework with monitoring.

HAX CMS CVE-2026-46493

EUVD-2026-34896 HIGH

Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) (CWE-338)

2026-06-05 GitHub_M

PHP Information Disclosure

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 05, 2026 - 21:01 EUVD

Source Code Evidence Fetched

Jun 05, 2026 - 19:50 vuln.today

Analysis Generated

Jun 05, 2026 - 19:50 vuln.today

DescriptionGitHub Advisory

HAX CMS helps manage microsite universe with PHP or NodeJs backends. Versions prior to 26.0.1 use uniqid for generating salts, which is unsuitable. Version 26.0.1 fixes the issue.

AnalysisAI

Weak cryptographic salt generation in HAX CMS (haxcms-php) versions prior to 26.0.1 allows remote unauthenticated attackers to predict or recover salt values used during installation and authentication-related operations. The flaw stems from using PHP's uniqid() - a timestamp-based, non-cryptographic function - as a randomness source (CWE-338). No public exploit has been identified at time of analysis and the CVE is not on CISA KEV.

Technical ContextAI

HAX CMS is a PHP/Node.js content management system from HAXTheWeb (cpe:2.3:a:haxtheweb:haxcms-php) used to manage microsite ecosystems. The vulnerable code in install.php (lines 188-191 of the referenced commit) relies on PHP's uniqid() to generate salts. uniqid() returns a value derived from the current microsecond timestamp and is documented as not cryptographically secure - its output is largely predictable to an attacker who can estimate when the value was generated, dramatically reducing the entropy that a salt is supposed to provide. CWE-338 (Use of Cryptographically Weak Pseudo-Random Number Generator) captures this root cause: a security-sensitive value was produced by a PRNG unsuitable for cryptographic use, weakening any downstream password hashing, token, or signature operations that depend on the salt.

RemediationAI

Vendor-released patch: upgrade haxcms-php to version 26.0.1 or later, which replaces uniqid() with a cryptographically suitable random source (fix commit https://github.com/haxtheweb/haxcms-php/commit/4b83cbdf8782c75bdcdd4f57ba72fba1c6dac147; advisory https://github.com/haxtheweb/issues/security/advisories/GHSA-xg43-xm47-74cp). After upgrading, operators should regenerate any salts, password hashes, session tokens, or API keys that were derived from the weak uniqid() output on pre-26.0.1 installs, and force a password reset for administrative accounts whose hashes may have been protected by a predictable salt - note this will log out existing users and invalidate stored credentials. If immediate upgrade is not possible, restrict network exposure of the HAX CMS admin and install endpoints (for example via IP allow-listing or placing the site behind authenticated VPN/SSO), accepting that this reduces normal accessibility for legitimate administrators.