CVE-2020-26276
Executive Summary
CVE-2020-26276 is a critical security vulnerability in Fleet, an open-source osquery management platform, affecting versions prior to 3.5.1. The flaw resides in the SAML authentication flow, where an attacker can exploit defects in Go's standard library XML parser to mutate a valid SAML response, thereby bypassing trust validation and allowing unverified logins from a SAML IdP. Organizations using Fleet with SSO/SAML login are exposed to authentication bypass, which can lead to full platform compromise given the CVSS score of 10.0.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability stems from a fundamental discrepancy between how Go's encoding/xml standard library parses XML documents and how the logical content of those documents is interpreted by downstream consumers. In SAML (Security Assertion Markup Language), the integrity and authenticity of authentication assertions are protected by XML digital signatures. The signature covers a canonicalized form of the XML document; however, if the XML parser used by the Service Provider (Fleet) reconstructs the document in a manner that differs from the canonical form that was signed, an attacker can inject or modify elements without invalidating the signature.
The specific issue class is known as "XML round-trip" or "XML parser differential" attacks. In Go's XML decoder, certain lexical constructs — such as whitespace handling within tags, character entity references, and attribute value normalization — may be parsed and re-serialized slightly differently from the original signed document, or the logical view of the tree may differ from the byte-level representation that was digested during signature validation. Mattermost's xml-roundtrip-validator (referenced in the advisory) is a tool designed to detect such discrepancies by enforcing strict round-trip equivalence between input and output of the XML parser.
Attack surface: The vulnerable component is the SAML Service Provider endpoint in Fleet, which accepts SAML Response objects (typically via HTTP POST binding) from the configured Identity Provider (IdP). Any attacker able to submit a crafted SAML response to this endpoint — without needing prior authentication — can attempt the exploit.
No specific function names or code paths are disclosed in the NVD description. The vulnerability is present in Fleet versions before 3.5.1; the fix enforces structural integrity of parsed XML before evaluating the SAML assertion.
Exploitation Scenarios
Note: No public PoC is available; attack chain is inferred from vulnerability class and the NVD description.
Reconnaissance / Target Identification: An attacker identifies a Fleet instance exposed to the internet or within a target network. Fleet's login page typically reveals SSO configuration. The attacker determines the SAML IdP endpoint (either a real corporate IdP or a rogue IdP they control) and the Fleet assertion consumer service (ACS) URL.
Triggering the Flaw: The attacker constructs a valid SAML Response object signed by an IdP (which could be a compromised/low-trust IdP, or a response they have previously observed from the legitimate IdP). Using the XML mutation technique, the attacker inserts an additional
<Attribute>element modifying the user's role or email, or alters theNameIDvalue — while preserving the original signature validity due to the parser differential. The crafted response is submitted to Fleet's SAML ACS endpoint.Payload / Execution Method: The payloAD is the mutated SAML XML document. Because Go's XML parser reconstructs the document in a way that hides the injected elements from the signature validation routine but exposes them to the authentication logic, Fleet accepts the response as authentic. The mutation effectively changes the identity or privileges of the authenticated user.
Post-Exploitation Impact: The attacker gains an authenticated session as a legitimate user — potentially an admin if they can elevate the role attribute. With administrative access to Fleet, the attacker can manage osquery configurations, deploy queries, retrieve sensitive host data, exfiltrate credentials, or pivot into managed endpoints.
Key observation: The attack requires that the SAML IdP be accessible to the attacker (or that they can relay/modify a captured response). In scenarios with a corporate IdP, the attacker may need to compromise the IdP first, or exploit this as a chain starting from another low-privilege account.
Impact Assessment
The CVSS score of 10.0 (Critical) reflects a network-exploitable vulnerability with no privileges required and no user interaction, affecting the confidentiality, integrity, and availability of the system and its data. However, exploitation technically requires the ability to submit a crafted SAML response to the Fleet endpoint — which is a remote, unauthenticated action.
- Business Impact: Full compromise of the Fleet management plane. Attacker gains visibility into and control over all managed osquery agents, which often run with elevated privileges on endpoints. This can lead to mass data exfiltration, ransomware deployment, or lateral movement across the enterprise.
- Affected Systems: All Fleet instances with SSO/SAML enabled running versions < 3.5.1. Environments with disabled SSO are not vulnerable.
- Blast Radius: The Fleet server itself, all registered osquery agents, and any systems reachable from compromised agents. The CVSS 10.0 suggests total loss of confidentiality, integrity, and availability across the scope.
Detection Guidance
The following detection rules focus on anomalous SAML responses, XML parsing errors, or authentication anomalies that indicate mutation attempts.
Sigma Rule
title: Suspicious SAML Response Mutation Attempt on Fleet
status: experimental
description: Detects failed or anomalous SAML authentication events on Fleet that may indicate XML round-trip validation failures.
logsource:
category: application
product: fleet
detection:
selection:
EventID:
- 'SAML_AUTH_FAILED'
- 'XML_VALIDATION_ERROR'
- 'SAML_PARSE_ERROR'
condition: selection
level: high
falsepositives:
- Misconfigured IdP (Identity Provider)
- Legitimate certificate rollover
YARA Rule
rule SAML_XML_Roundtrip_Mutation
{
meta:
author = "Valter Security"
description = "Detects suspicious XML constructs in SAML responses that may indicate signature bypass attempts."
date = "2025-04-11"
strings:
$saml = "<samlp:Response" ascii nocase
$dup_attr = "<saml:Attribute " ascii nocase
$entity_ent = "&" ascii
$entity_lt = "<" ascii
$ws_in_tag = /\w+[\t ]+=[\t ]+"/ ascii
condition:
$saml and (#dup_attr > 5) and ($entity_ent or $entity_lt or $ws_in_tag)
}
Suricata IDS Rule
alert http any any -> $FLEET_SERVERS any (
msg:"Suspicious SAML Response Post to Fleet - XML Mutation Attempt";
flow:to_server;
http.method; content:"POST";
http.uri; content:"/sso/assert";
http.request_body; content:"<samlp:Response"; nocase;
http.request_body; content:"<saml:Attribute"; nocase;
pcre:"/<\w+[\t ]+[a-zA-Z]+=[^>]*[\t ]+[a-zA-Z]+=/";
classtype:attempted-admin;
sid:3000015; rev:1;
)
Elastic Detection
sequence by host.name, source.ip
[ authentication where event.outcome == "failure"
and process.name == "fleet"
and message contains "SAML" ]
[ authentication where event.outcome == "success"
and process.name == "fleet"
and source.ip == same as previous
and within 5 minutes ]
Splunk SPL Query
index=main sourcetype=fleet:logs
| where like(SAAS_SAML_AUTH, "%failure%") OR like(SAAS_SAML_PARSE_ERR, "x")
| table _time, source_ip, user, event, error_message
| sort - _time
Wazuh OSSEC Rule
<rule id="100098" level="10">
<decoded>json.fleet_log</decoded>
<field name="event">SAML_AUTH_FAILED</field>
<description>Fleet detected SAML authentication failure. Potential XML round-trip mutation attempt.</description>
<group>authentication_failures,saml,</group>
</rule>
Mitigation & Patch Guidance
Patch confidence is 0/4 — no patch evidence is available from any tracked source in the provided data; however, the NVD description explicitly states the issue is fixed in Fleet version 3.5.1.
Immediate Mitigations:
- If upgrade is not immediately possible, disable SSO authentication in Fleet as stated in the advisory. This eliminates the attack surface.
- Restrict network access to the Fleet SAML ACS endpoint (typically
/api/v1/fleet/ssoor similar) via firewall rules or reverse proxy allowlisting of known IdP IP addresses. - Enable multi-factor authentication at the IdP level as defense-in-depth.
Patch / Upgrade Steps:
- Upgrade Fleet to version 3.5.1 or later. The fix integrates
https://github.com/mattermost/xml-roundtrip-validatorinto the SAML parsing flow. See Fleet's official release notes for upgrade procedures. - Verify the upgrade by re-running SAML integration tests.
- Upgrade Fleet to version 3.5.1 or later. The fix integrates
Long-Term Hardening:
- Enforce strict SAML response schema validation at the reverse proxy level (e.g., using a WAF).
- Monitor for unusual SAML responses, primarily those containing unexpected attributes or verbose entity declarations.
- Keep Fleet and Go runtime updated; track CVE-2020-26276 in vulnerability management systems.
- If SSO is not required, keep it disabled. If required, follow the principle of least privilege for SAML role mapping.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2020-26276
- Fleet GitHub Advisory: https://github.com/fleetdm/fleet/security/advisories/GHSA-XXXX (referenced via CNA title)
- Mattermost xml-roundtrip-validator: https://github.com/mattermost/xml-roundtrip-validator
- Go XML parser issue discussion: https://github.com/golang/go/issues/XXXXX (related parser differential bug reports)
- CISA KEV: NO — this CVE is not listed in the Known Exploited Vulnerabilities catalog.
Threat Actor / Exploit-in-the-Wild Evidence: No public exploit code or in-the-wild exploitation reports are known at time of writing. EPSS score (0.02168) indicates a low observed exploitation rate, but the CVSS 10.0 severity warrants immediate patching.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.