A critical vulnerability in UNISOC modem firmware allows one User Equipment (UE) to remotely attack another over the cellular network. By sending specially crafted malformed SDP within SIP signaling messages, an attacker can trigger memory corruption in the target modem, potentially leading to remote execution of arbitrary native code on the victim device.

[research writeup](https://www.codeant.ai/security-research/security-research-simple-git-remote-code-execution-cve-2026-28292)

simple-git, 5M+ weekly npm downloads. the bypass is through case-sensitivity handling, subtle enough that traditional SAST wouldn't catch it.

found by the same team (codeant ai) that found CVE-2026-29000, the CVSS 10.0 pac4j-jwt auth bypass that sat undiscovered for 6 years.

interesting pattern: both vulns were found by AI code reviewer, not pattern-matching scanners.

We’ve disclosed CVE-2026-26117 affecting Azure Arc on Windows: a high severity local privilege escalation that can also be used to take over the machine’s cloud identity.

In practical terms, this means a low-privileged user on an Arc-joined Windows host may be able to escalate to higher privileges and then abuse the Arc identity context to pivot into Azure.

If you’re running Azure Arc–joined Windows machines and your Arc Agent services are below v1.61, assume you’re impacted update to v1.61.

I built a pipeline and map that classifies where Swiss municipalities host their email by probing public DNS records. I wanted to find out how much uses MS365 or other US clouds, based on public data:

screenshot of map

• Interactive map: https://mxmap.ch
• Code: https://github.com/davidhuser/mxmap

The classification uses a hierarchical decision tree:

1. MX record keyword matching (highest priority) — direct hostname patterns for Microsoft 365 (mail.protection.outlook.com), Google Workspace (aspmx.l.google.com), AWS SES, Infomaniak (Swiss provider)
2. CNAME chain resolution on MX hostnames — follows aliases to detect providers hidden behind vanity hostnames
3. Gateway detection — identifies security appliances (e.g. Trend Micro etc.) by MX hostname, then falls through to SPF to identify the actual backend provider
4. Recursive SPF resolution — follows include: and redirect= chains (with loop detection, max 10 lookups) to expand the full SPF tree and match provider keywords
5. ASN lookup via Team Cymru DNS — maps MX server IPs to autonomous systems to detect Swiss ISP relay hosting (SWITCH, Swisscom, Sunrise, etc.). For these, autodiscover is checked to see if a hyperscaler is actually behind the relay.
6. Autodiscover probing (CNAME + _autodiscover._tcp SRV) — fallback to detect hidden Microsoft 365 usage behind self-hosted or ISP-relayed MX
7. Website scraping as last resort — probes /kontakt, /contact, /impressum pages, extracts email addresses (including decrypting TYPO3 obfuscated mailto links), then classifies the email domain's infrastructure

Key design decisions:

• MX takes precedence over SPF
• Gateway + SPF expansion is critical — many municipalities use security appliances that mask the real provider
• Three independent DNS resolvers (system, Google, Cloudflare) for resilience
• Confidence scoring (0–100) with quality gates (avg ≥70, ≥80% high-confidence)

Results land in 7 categories: microsoft, google, aws, infomaniak, swiss-isp, self-hosted, unknown.

Where I'd especially appreciate feedback:

• Do you think this a good approach?
• Are there MX/SPF patterns I'm missing for common provider setups?
• Edge cases where gateway detection could misattribute the backend?
• Are there better heuristics than autodiscover for detecting hyperscaler usage behind ISP relays?
• Would you rather introduce a new category "uncertain" instead, if so for which cases?

Thanks!