CVE-2026-23933

Executive Summary

CVE-2026-23933 is a hardcoded cryptographic key weakness (CWE-259) in Zabbix 7.4: the key used to sign Frontend session cookies was erroneously written into the database seed. The only known exploitable configuration is a Zabbix 7.4 deployment that has both SAML authentication and guest users enabled, where an attacker who obtains the seed-derived key can forge valid session cookies and achieve unauthorized access to the monitoring frontend. No public exploit, no vendor patch, and no in-the-wild exploitation evidence exist at the time of writing; CVSS and EPSS scores are not available.

Technical Analysis

The vulnerability resides in the session-validation trust boundary of the Zabbix 7.4 web frontend. Web frontends typically protect session cookies by signing them with a server-side secret so that a client cannot tamper with the session payload (for example, the username or role identifier) without invalidating the signature. If the signing secret is known to an attacker, signature forgery becomes trivial: the attacker can construct an arbitrary session payload, compute the valid signature, and present the resulting cookie to the application, which then accepts it as legitimate.

According to the NVD description, Zabbix 7.4 erroneously placed that signing key into the database seed. A database seed is the initialization dataset (SQL statements and reference data) used when provisioning a new Zabbix database. Shipping the session-signing key as part of the seed has two security consequences:

1. Static secret across deployments — if the seed is distributed with the product or regenerated in a predictable way, every installation that was initialized from the affected seed will use the same signing key material. This converts a per-deployment secret into a shared, effectively hardcoded credential (CWE-259: Use of Hard-coded Password).
2. Credential disclosure without server compromise — an attacker does not need to compromise the Zabbix server to obtain the key; it is recoverable from any copy of the seed artifact (distribution archives, container layers, backups, public code repositories, insider access).

The description explicitly bounds the currently known exploitation scenario to deployments that use both SAML authentication and guest users. The exact code path is not disclosed in the available data. Based on the vulnerability class, the likely mechanism is that the SAML/guest combination provides a session-validation path in which an attacker-supplied cookie is accepted without an interactive authentication exchange (the normal password or SSO assertion flow). On the affected configuration, a forged cookie can therefore bypass authentication and be treated as a valid frontend session. For all other Zabbix 7.4 deployments — those without SAML or without guest users — the description states that there is no known impact.

Insufficient technical detail is available to name the affected seed file, the exact session cookie structure, or the signing algorithm. The analysis above is at the vulnerability-class level and is consistent with the NVD description.

Attack surface. The frontend is an internet-facing web application in many production deployments. Any network path to the Zabbix frontend is an attack vector. Access to the seed artifact expands the attacker's capability from "session hijacking requires interception" to "session forgery requires only the seed." The flaw does not affect TLS/transport encryption or database authentication material; it undermines the integrity of the authentication boundary itself.

Exploitation Scenarios

No public PoC is available, so the following attack chain is inferred from the vulnerability class and the preconditions explicitly described in the NVD description.

Step 1 — Reconnaissance and target identification. The attacker identifies Zabbix 7.4 frontends exposed to the network, using banner/title fingerprinting of the login page or service metadata. The attacker then determines whether the target uses SAML authentication and whether guest users are enabled. These two features are the known preconditions for exploitation; only targets with both are viable.

Step 2 — Obtain the signing key. The attacker obtains a copy of the affected database seed. Practical acquisition channels include public distribution artifacts, container images, exposed backup repositories, or any file disclosure that leaks the initialization data. Because the key is embedded in the seed, no live interaction with the target server is required at this stage.

Step 3 — Forge the session cookie. Using the recovered key, the attacker crafts a session cookie with a chosen session payload and computes the corresponding cryptographic signature. This is performed entirely offline; the target server is not contacted during the forgery step. At the vulnerability-class level, this is equivalent to possessing the server's session-validation secret.

Step 4 — Present the forged cookie and access the frontend. The attacker sends an HTTP request to the Zabbix frontend carrying the forged session cookie. On the affected SAML + guest-user configuration, the server accepts the cookie as a valid session and grants access without requiring credentials or a SAML assertion. The resulting access level depends on the privileges bound to the forged session context; guest users are typically low-privileged, but the underlying flaw — the known, seed-derived signing key — means the cryptographic guarantee of the session mechanism is broken for the affected deployment.

Post-exploitation impact includes unauthorized viewing of monitoring data, dashboards, host configuration, and any operational information the Zabbix frontend exposes to authenticated users. If a forged session can be mapped to a more privileged identity, the impact could extend to configuration changes and disruption of monitoring workflows; the available description does not confirm arbitrary user impersonation, so this is noted as a potential rather than a confirmed outcome.

Impact Assessment

The primary impact is a confidentiality and access-control breach: an attacker with access to the seed artifact can bypass authentication on affected Zabbix 7.4 frontends. Zabbix is a central monitoring platform; it aggregates sensitive operational telemetry, host inventories, network topology, and often integrates with other systems. Unauthorized access to this data aids further reconnaissance against the monitored environment.

Known exploitable configuration. SAML authentication enabled and guest users enabled. Non-SAML deployments and deployments without guest users are described as having no known impact — however, the existence of a static session-signing key in the seed is a latent weakness even where no exploitation path is currently known.

Blast radius. The flaw is bounded to Zabbix 7.4 and to specific feature combinations, which limits the absolute population of affected systems. However, if the seed is distributed identically across installations, the key is shared globally, making the issue systematic rather than instance-specific — an attacker who obtains the key once can evaluate it against every exposed Zabbix 7.4 frontend. This raises the attractiveness of the target set for mass scanning.

Severity scoring. CVSS is N/A — no vector or score has been assigned by the CNA/NVD, so quantitative severity cannot be cited. EPSS has not been scored by FIRST.org, so automated exploitation-likelihood data is unavailable. CISA KEV does not list this CVE, and no threat-actor campaigns or exploit-in-the-wild evidence have been reported in the available intelligence.

Detection Guidance

Detection is difficult because exploitation is primarily offline (cookie forging) followed by online presentation of a valid-looking cookie. The resulting network traffic is not distinguishable from legitimate session use by content inspection alone. The rules below are heuristic and target the observable anomaly: a session cookie being accepted on a Zabbix frontend without a preceding authentication event, or anomalous cookie/session behavior. Field names must be adapted to each organization's logging schema. No Zabbix-internal identifiers (cookie names, endpoints) are referenced, as they are not disclosed in the available data.

Sigma Rule

title: Zabbix Frontend Session Use Without Prior Authentication
id: 8b0f9c0e-2c34-4f10-9a6d-3c57a2b1f001
status: experimental
description: >
  Detects successful HTTP requests to a Zabbix frontend that carry a session
  cookie but are not preceded by an authentication (login) event. Heuristic
  detection for CVE-2026-23933 (forged frontend session cookies) and similar
  session-forgery scenarios.
logsource:
  category: webserver
  product: zeek
detection:
  selection_success:
    http.response.status_code: 200
  selection_session_cookie:
    http.request.headers.cookie|contains: session
  selection_zabbix:
    http.response.headers.server|contains: Zabbix
  filter_known_auth:
    # A login POST containing credentials observed from the same source
    # within the correlation window should be excluded (pseudo-correlation;
    # implement as a lookup against recent authentication events).
    http.request.body|contains: password
  condition: selection_success and selection_session_cookie and selection_zabbix and not filter_known_auth
falsepositives:
  - Long-lived legitimate user sessions where the login event predates the log retention window
  - Session cookie names containing the substring "session" in non-Zabbix applications
  - Proxies that rewrite or strip authentication cookies
level: high
fields:
  - source.ip
  - http.request.headers.cookie
  - http.response.status_code

YARA Rule

rule CVE_2026_23933_Zabbix_Seed_SigningKey_Hunt
{
    meta:
        author      = "Valters IT Threat Intelligence"
        description = "Hunt for Zabbix database seed artifacts that may contain the frontend session-signing key disclosed in CVE-2026-23933."
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-23933"
        date        = "2026-05-01"
        severity    = "high"

    strings:
        $sql_insert = "INSERT INTO" ascii nocase
        $zabbix     = "zabbix" ascii nocase
        $session    = "session" ascii nocase
        $key_ref    = "signing_key" ascii nocase
        $key_alt    = "session_key" ascii nocase
        $sign_ref   = "sign" ascii nocase
        $crypto_ref = "crypt" ascii nocase

    condition:
        uint16(0) == 0x0A23 or $sql_insert
        and $zabbix and $session
        and ( $key_ref or $key_alt or ($sign_ref and $crypto_ref) )
}

Note: This is a forensic hunting rule intended to locate seed artifacts on disk, in repositories, in backups, or in extracted container layers. The exact key format and seed-file structure are not disclosed in the available intelligence; adjust the strings once a fixed and affected version can be diffed.

Suricata IDS Rule

Two rule complement with flowbits models the authentication flow: rule A records a successful login POST; rule B alerts when a session cookie is presented on the same flow without that authentication having occurred.

# Rule A: mark flows where a Zabbix frontend login POST was observed
alert http any any -> any any (msg:"ET WEB_SERVER Zabbix Frontend Login POST Observed (CVE-2026-23933 context)"; flow:to_server,established; http.host; content:"zabbix"; nocase; http.method; content:"POST"; http.request_body; content:"password"; flowbits:set,zabbix_frontend_auth; flowbits:noalert; classtype:not-suspicious; sid:10000001; rev:1;)

# Rule B: session cookie presented without prior login on the same flow — possible forged session (CVE-2026-23933)
alert http any any -> any any (msg:"ET WEB_SERVER Zabbix Frontend Session Cookie Without Prior Login - Possible CVE-2026-23933 Forgery"; flow:to_server,established; flowbits:isnotset,zabbix_frontend_auth; http.host; content:"zabbix"; nocase; http.cookie; content:"session"; nocase; classtype:attempted-user; sid:10000002; rev:1;)

Limitations: the rules match the host string "zabbix" and the cookie substring "session" heuristically; legitimate traffic in deployments where the login POST body is encrypted, or where a third-party SSO performs authentication out-of-band, will generate false positives. Tune per environment.

Elastic Detection

sequence by source.ip with maxspan=10m
  [ http where
      response.status_code == 200 and
      request.headers.cookie like "*session*" and
      url.host like "*zabbix*" ]
  until
  [ http where
      request.method == "POST" and
      request.body like "*password*" and
      url.host like "*zabbix*" ]

Explanation: EQL until terminates a sequence when the terminating event occurs. If a successful Zabbix frontend request carrying a session cookie is seen from a given source IP and no login POST is observed from the same IP within the 10-minute window, the sequence completes and an alert is generated. This flags cookie presentation without observed authentication — the network-observable fingerprint of CVE-2026-23933 exploitation.

Splunk SPL Query

index=web sourcetype=access_combined
| stats
    values(cookie) as session_cookies,
    count as total_requests,
    count(eval(method="POST" AND like(_raw, "%password%"))) as auth_posts
  by src_ip, host
| where total_requests > 10 AND auth_posts == 0 AND like(session_cookies, "%session%")
| eval alert_reason = "Zabbix 7.4 frontend session cookie use without observed login POST - potential CVE-2026-23933 session forgery"
| table _time, src_ip, host, total_requests, auth_posts, session_cookies, alert_reason

Supplementary query — anomalous guest-user activity in Zabbix audit logs (adjust sourcetype to the local Zabbix log ingestion):

index=zabbix sourcetype=zabbix_audit user=guest
| stats count as guest_actions by user, resource, src_ip
| where guest_actions > 50
| eval note = "Elevated guest-user activity on Zabbix frontend - investigate for CVE-2026-23933 forged sessions"

Wazuh OSSEC Rule

<group name="zabbix,web,">
  <!-- CVE-2026-23933: Zabbix frontend session cookie usage without preceding authentication -->
  <rule id="100239" level="12">
    <decoded_as>web-access</decoded_as>
    <match>Zabbix</match>
    <regex>session</regex>
    <description>CVE-2026-23933 - Zabbix frontend session cookie presented without observed login POST; possible forged session</description>
    <group>authentication_failures,web_attack,</group>
  </rule>

  <!-- Elevated guest-user activity in Zabbix audit logs -->
  <rule id="100240" level="10">
    <if_sid>100239</if_sid>
    <match>guest</match>
    <description>CVE-2026-23933 - Increased guest-user activity on Zabbix frontend; verify session source</description>
    <group>authentication_failures,</group>
  </rule>
</group>

Verify that the Wazuh decoder in use extracts the web-access fields and that the Zabbix audit log source is forwarded, otherwise adapt the <decoded_as> and match strings.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source, and no vendor fix is referenced in the available intelligence. The following guidance is therefore ordered from immediate containment to long-term hardening.

1) Immediate mitigations (until a vendor fix is available)

• Disable guest users on all Zabbix 7.4 deployments. This removes one of the two preconditions required for the known exploitation scenario.
• Disable or defer SAML authentication on Zabbix 7.4 frontends where it is not business-critical; the known attack path requires both SAML and guest users.
• Treat database seed artifacts as sensitive credentials. Restrict access to installation media, database initialization dumps, backups, and container layers containing the Zabbix seed. Scan internal repositories and image registries for copies of the seed.
• Restrict network exposure of the Zabbix frontend to trusted networks or via authenticated reverse proxy / VPN; do not expose it directly to the internet if avoidable.
• Monitor for the detection patterns above, particularly cookie-presenting sessions with no corresponding login event and unusual guest-user activity.

2) Patch / upgrade steps

• No fixed version is currently known. Subscribe to Zabbix security advisories and track this CVE for an assigned advisory identifier.
• When a fixed 7.4.x (or later) release is published, upgrade all affected frontend and server components, and re-initialize session-signing key material if the vendor documents that as a requirement.
• Before patching, consider whether the deployment architecture permits regenerating the frontend session-signing key to diverge from the hardcoded seed value; this is a deployment-specific action and should be validated against vendor documentation.

3) Long-term hardening

• Maintain an asset inventory of all Zabbix 7.4 systems and their feature configuration (SAML, guest users, network exposure) to prioritize remediation.
• Integrate secret-scanning into CI/CD and backup pipelines to detect embedded cryptographic material in seed artifacts.
• Establish a key-rotation program for web-frontend session signing keys; hardcoded or seed-derived keys should be replaced with deployment-unique, rotated secrets.
• Deploy a WAF or reverse proxy capable of flagging session-cookie-only access patterns to the frontend.
• Re-evaluate this CVE when CVSS and EPSS scores are published; currently neither is available, and CISA KEV has not listed this vulnerability, indicating no confirmed in-the-wild exploitation to date.

References

1. NVD Entry — CVE-2026-23933: https://nvd.nist.gov/vuln/detail/CVE-2026-23933
2. MITRE CVE Record — CVE-2026-23933: https://www.cve.org/CVERecord?id=CVE-2026-23933
3. CWE-259 — Use of Hard-coded Password: https://cwe.mitre.org/data/definitions/259.html
4. Zabbix Official Site — monitor the security advisories section for a future fixed release: https://www.zabbix.com
5. CISA Known Exploited Vulnerabilities Catalog — CVE-2026-23933 is not listed; no in-the-wild exploitation campaigns have been reported in the available intelligence. EPSS has not yet been scored by FIRST.org.

Reporting note: The CNA title and vendor advisory URL are not provided in the available intelligence. No threat-actor campaigns, exploit code, or Nuclei templates associated with this CVE have been identified at the time of writing.