We recently published a paper showing how generative AI can dramatically reduce the barrier to entry for robot hacking.

Using Cybersecurity AI (CAI), we analyzed three real consumer robots:

• a robotic lawn mower

• a powered exoskeleton

• a window-cleaning robot

In ~7 hours the system identified 38 vulnerabilities including:

– firmware exploitation paths

– BLE command injection

– unauthenticated root access

– safety-critical control exposure

Historically, uncovering these kinds of vulnerabilities required weeks or months of specialized robotics security research.

The paper argues that we are entering a new phase where AI-assisted attackers can scale faster than traditional robot security defenses.

We also discuss the implications for consumer robotics privacy, safety and regulatory compliance (e.g. GDPR).

Paper (arXiv):

https://arxiv.org/pdf/2603.08665

Happy to answer technical questions.

A high-severity (CVSS 7.8) security feature bypass in Microsoft Office is being actively exploited in the wild, with a public PoC already available and the vuln now on CISA's KEV catalog. Root cause is unvalidated input handling (CWE-807) that allows malicious OLE/COM objects in crafted documents to bypass built-in protections. Attack vector is local with no privileges required — just a user opening a phishing-delivered Office file. Affects Office 2016, 2019, LTSC 2021/2024, and Microsoft 365 Apps on x86/x64. Microsoft dropped an out-of-band emergency patch on January 26, 2026. Office 2016/2019 also require a registry-based mitigation. Confirmed targeting of government agencies, critical infrastructure, and maritime/transport sectors.

• MicroStealer exposes a broader business risk by stealing browser credentials, active sessions, and other sensitive data tied to corporate access.
• The malware uses a layered NSIS → Electron → JAR chain that helps it stay unclear longer and slows confident detection.
• Distribution through compromised or impersonated accounts makes the initial infection look more trustworthy to victims.

Update (March 13, 2026):

Several major developments since this was posted:

1. Packet Storm Security — Advisory published: https://packetstorm.news/files/id/217089

2. Apple Product Security — Confirmed forwarding to investigation team (Ticket OE01052449093014). Apple is actively investigating Alipay iOS app.

3. Google Play — Policy violation investigation confirmed (Case #9-7515000040640).

4. Singapore PDPC — Formal investigation opened (Case #00629724).

5. HKCERT — Forwarded report to CNCERT (China National CERT).

6. MITRE CVE — 6 CVEs pending (Ticket #2005801), CVSS 7.4–9.3.

Vendor (Ant Group) continues to maintain these are "normal functionality" and has issued no patch.

Full report: https://innora.ai/zfb/

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!