Pwn2Own Ireland 2026: 32 Zero-Days, Samsung Galaxy S26 Hacked Twice — What Defenders Must Do Now

Day one of Pwn2Own Ireland 2026 closed with a number every CISO should have pinned to a whiteboard: 32 zero-day vulnerabilities exploited in a single day, with $388,500 paid out to competing research teams. The headline result — the Samsung Galaxy S26 was successfully compromised twice by two independent teams — confirms what those of us who track mobile exploitation already know: flagship mobile devices with the latest silicon and the latest OS builds remain tractable targets for a skilled, motivated exploit developer.

Here is the critical nuance defenders need to internalize: Pwn2Own is a controlled disclosure event. The vulnerabilities demonstrated are reported privately to the affected vendors under Zero Day Initiative's coordinated disclosure process, and technical details stay embargoed — typically for 90 days — while patches are developed. That means right now, you are in the most dangerous window: the bugs are proven exploitable, working exploit chains exist, no public detection signatures exist, and no patches have shipped. Anything demonstrated at Pwn2Own is also within reach of well-resourced threat actors running parallel research programs. Mobile zero-click and one-click exploit chains of exactly this class have historically surfaced in commercial spyware operations within months of public proof-of-concept demonstrations.

This post is your defensive playbook for that window: what was demonstrated, what the attack surface looks like, what you can detect today without signatures, and how to harden your mobile and browser fleet before the patch wave arrives.

Technical Analysis

What happened

• Event: Pwn2Own Ireland 2026, day one
• Result: 32 zero-day vulnerabilities successfully exploited across the competition's target categories
• Headline target: Samsung Galaxy S26 — fully compromised in two separate demonstrations by independent research teams
• Payouts: $388,500 awarded on day one alone, indicating high success rates against fully patched, current-generation targets

Pwn2Own targets are always the latest, fully patched builds at contest time. That is the point — contestants only earn Master of Pwn points for exploits against current software with all available updates applied. So when you read "Galaxy S26 hacked twice," translate it as: two distinct exploit chains exist today against the shipping, fully updated flagship Android device your executives are carrying.

The affected attack surface

While full technical details remain under embargo pending vendor patches, Pwn2Own's mobile category structure and historical precedent tell us the shape of these chains with high confidence. A successful mobile handset demonstration at Pwn2Own requires a full chain: initial code execution plus privilege escalation/sandbox escape to achieve the required level of device control. The realistic component targets on a Galaxy S26-class device include:

• Browser renderer (Chrome/Samsung Internet — Chromium engine): renderer compromise via type confusion, use-after-free, or JIT bugs is the classic chain entry point
• Android WebView: the same renderer attack surface, reachable through any third-party app that renders web content — massively expanding the delivery surface beyond the browser itself
• MMS/messaging parsing paths: the zero-click delivery vector of choice; image and media codec parsing has produced multiple Pwn2Own wins and, more importantly, multiple real-world spyware chains
• Baseband / connectivity stack: contest categories routinely include baseband and Wi-Fi/Bluetooth attacks requiring no user interaction at all
• Privilege escalation stage: Android kernel or Samsung-specific driver exploitation to escape the app sandbox and SELinux policy

The two independent S26 compromises almost certainly used different chains — different entry bugs, possibly different escalation bugs — which matters for defense: you are not hunting one bug, you are hardening against a class of exploitation.

CVEs, CVSS, and exploitation status — read this carefully

• CVE identifiers: None have been publicly assigned yet. Under ZDI's coordinated disclosure, CVEs are assigned as vendors ship fixes. Any blog or feed claiming a CVE for these bugs today is fabricating. Expect assignments in the Samsung security bulletin and Chromium/Chrome release notes over the coming 90-day window.
• CVSS scores: Not yet published. Historically, full mobile chains decompose into a high-severity renderer/RCE bug (typically CVSS 8.x) chained with a high-severity local privilege escalation (7.x–8.x).
• In-the-wild exploitation: There is no confirmed in-the-wild exploitation of these specific bugs as of this writing — they are demonstrated, embargoed vulnerabilities. But treat this as a pre-KEV situation: CISA KEV listing for Pwn2Own-derived bugs has followed public disclosure with increasing speed, and the commercial surveillance industry actively replicates demonstrated techniques. Your operational posture should be "assumed imminent."
• PoC availability: Working exploits exist in the hands of the winning research teams and are now in the hands of the affected vendors. No public PoC exists yet — but disclosure writeups after patch release typically provide enough detail for adversary re-implementation within days.

Why this matters beyond the Galaxy S26

32 zero-days in one day spans the full contest scope — browsers, mobile handsets, messaging-adjacent targets, and the other categories in play at the Ireland event. The defensive lesson generalizes: the exploit economy is healthy, talent is deep, and fully patched current-generation software is being reliably broken on a stage, on a timer, for money. Your patch-latency and detection-depth assumptions must account for this as the baseline, not the exception.

Detection & Response

The uncomfortable truth: you cannot signature-detect an embargoed zero-day. There are no IoCs, no hashes, no CVEs. What you can do — and what mature SOCs do — is detect the behavioral artifacts of exploit-chain execution. Exploit chains leave fingerprints that are invariant regardless of which specific bug delivered the payload: renderers spawning shells, browser processes crashing in tight loops, media parsing services faulting, unexpected child processes of messaging apps. These detections are durable, low-noise when scoped properly, and they will still be firing usefully when the next Pwn2Own class of bugs drops.

Sigma Rules

The first rule targets the canonical post-exploitation artifact of a browser/renderer exploit chain on managed Windows endpoints: a browser process spawning a shell, script interpreter, or LOLBin. The second targets exploitation-attempt telemetry — repeated crashes of browser renderer or media parsing processes, which is what failed exploit attempts look like in fleet telemetry. Scope the crash-loop rule to tight time windows to keep noise manageable.

---
title: Browser Process Spawning Shell or Script Interpreter
title_note: Post-exploitation artifact of renderer exploit chains
id: 3f9a1c74-2b8e-4d51-a6c3-9e1f4a7b8d20
status: experimental
description: Detects web browser processes spawning command shells, script interpreters, or LOLBins. This is the canonical post-exploitation behavior of a successful browser/renderer exploit chain, as demonstrated in Pwn2Own-style full-chain compromises. Renderer exploitation followed by sandbox escape frequently drops to cmd, PowerShell, or mshta for payload staging.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-exploit-32-zero-days-on-first-day-of-pwn2own-ireland/
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1203
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\opera.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare enterprise browser extensions invoking external tools (investigate, do not whitelist blindly)
  - Some password manager or SSO broker integrations
level: high
---
title: Repeated Crash of Browser Renderer or Media Parser Process
title_note: Exploit attempt telemetry — failed heap grooming produces crash loops
id: 8c2e5b91-4d7a-4f36-b158-6a3d9c0e1f47
status: experimental
description: Detects application error events for browser renderer processes or media parsing components. Failed exploitation attempts (heap grooming failures, offset mismatches) characteristically produce repeated renderer crashes in tight succession. A single crash is noise; a crash loop clustered in time on one host is a hunt-worthy signal, particularly when correlated with browsing of newly registered or low-reputation domains.
references:
  - https://www.bleepingcomputer.com/news/security/hackers-exploit-32-zero-days-on-first-day-of-pwn2own-ireland/
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1203
logsource:
  category: application
  product: windows
detection:
  selection:
    Provider_Name: 'Application Error'
    Data|contains:
      - 'chrome.exe'
      - 'msedge.exe'
      - 'msedgewebview2.exe'
      - 'firefox.exe'
  condition: selection
falsepositives:
  - Legitimate renderer instability from buggy extensions or driver conflicts — triage by frequency per host and correlation with network telemetry
level: medium

KQL (Microsoft Sentinel / Defender)

This hunt surfaces the exploit-chain artifact directly: browser and WebView processes spawning unusual children. WebView2 (msedgewebview2.exe) is included deliberately — it is Chromium's renderer running inside third-party apps and is an under-monitored delivery surface, directly analogous to the Android WebView exposure on the mobile side. The query aggregates by device and parent process to keep analyst triage fast, and excludes known-noisy patterns.

// Hunt: Browser/WebView renderer exploit chain artifact — browser spawning shells or LOLBins
// Relevant to Pwn2Own-class full-chain exploitation (T1203 -> T1059)
let Lookback = 7d;
let SuspiciousChildren = dynamic([
  "cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
  "mshta.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe",
  "certutil.exe", "bitsadmin.exe", "msbuild.exe", "installutil.exe"
]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ (
    "chrome.exe", "msedge.exe", "msedgewebview2.exe",
    "firefox.exe", "brave.exe", "opera.exe")
| where FileName in~ (SuspiciousChildren)
| where not (  // Exclude the known-noisy pattern: browsers launching rundll32 for printing
    FileName =~ "rundll32.exe" and ProcessCommandLine has "printui.dll")
| summarize
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    ChildProcesses = make_set(FileName),
    CommandLines = make_set(ProcessCommandLine, 10),
    ParentCommandLine = any(InitiatingProcessCommandLine),
    Accounts = make_set(AccountName)
    by DeviceName, InitiatingProcessFileName
| extend ChildCount = array_length(ChildProcesses)
| order by FirstSeen desc

Correlate any hits against DeviceNetworkEvents for the same device in the preceding hour — a renderer compromise is almost always preceded by a connection to an attacker-controlled or compromised site. A browser spawning powershell.exe within minutes of a connection to a newly registered domain is a five-alarm triage, not a ticket.

Velociraptor VQL

For DFIR teams doing live triage on a suspected-compromised endpoint, this artifact enumerates browser processes with their child processes in one pass — exactly what you need to confirm or rule out chain execution without an EDR console.

-- Artifact: Browser exploit chain triage — enumerate browser processes and their children
-- Use: live response on endpoints suspected of browser/WebView-driven compromise

LET browser_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)chrome|msedge|firefox|brave|opera|msedgewebview2'

LET browser_pids = SELECT Pid FROM browser_procs

SELECT child.Pid AS ChildPid,
       child.Ppid AS ParentPid,
       child.Name AS ChildName,
       child.Exe AS ChildExe,
       child.CommandLine AS ChildCommandLine,
       child.Username AS ChildUsername,
       child.CreateTime AS ChildCreateTime,
       parent.Name AS ParentBrowser,
       parent.CommandLine AS ParentCommandLine
FROM pslist() AS child
JOIN browser_procs AS parent ON child.Ppid = parent.Pid
WHERE child.Name =~ '(?i)cmd\.exe|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|wmic|certutil|bitsadmin'

Mobile Fleet Telemetry (the S26 side)

You cannot run Sigma on a Galaxy S26. Your mobile detection surface is your MDM/MTD telemetry (Microsoft Defender for Endpoint on Android, Lookout, Zimperium, or your MDM's compliance stream) ingested into the SIEM. During this embargo window, hunt for:

• Devices reporting unexpected full-device reboots or repeated SystemUI/renderer crashes in tight succession — failed exploit attempts against messaging/browser targets frequently destabilize the device before a successful run
• Devices with Play Integrity / SafetyNet attestation failures or sudden drops in attestation state
• Sideloaded APKs or unexpected packages appearing on devices, especially outside enrollment provisioning windows
• Network egress from mobile devices to newly registered or DGA-patterned domains (from your proxy/DNS telemetry if devices are on managed Wi-Fi or VPN)

Remediation Script

No patch exists yet for the Pwn2Own bugs — so this script does what you can do today: audits your Android fleet's security patch level via ADB (the first thing you will need when Samsung's bulletin ships) and verifies enforcement of the hardening controls that raise the cost of the most common delivery vectors.

#!/usr/bin/env bash
# audit_android_patch_fleet.sh
# Security Arsenal — Pwn2Own Ireland 2026 response
# Audits enrolled Android devices for security patch level and key hardening state.
# Prereqs: adb authorized against target device (or run via your MDM's script channel).
set -euo pipefail

OUTFILE="android_patch_audit_$(date +%Y%m%d_%H%M%S).csv"
echo "serial,model,android_version,security_patch,play_integrity_note,sideload_risk" > "$OUTFILE"

# Define your minimum acceptable patch level here.
# Update this the day Samsung's post-Pwn2Own bulletin ships.
MIN_PATCH="2025-12-01"

for SERIAL in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
  MODEL=$(adb -s "$SERIAL" shell getprop ro.product.model | tr -d '\r')
  AVER=$(adb -s "$SERIAL" shell getprop ro.build.version.release | tr -d '\r')
  PATCH=$(adb -s "$SERIAL" shell getprop ro.build.version.security_patch | tr -d '\r')
  # Unknown sources / sideloading state (0 = blocked, 1 = allowed)
  SIDELOAD=$(adb -s "$SERIAL" shell settings get global install_non_market_apps 2>/dev/null | tr -d '\r')
  SIDELOAD=${SIDELOAD:-unknown}

  RISK="OK"
  if [[ "$PATCH" < "$MIN_PATCH" ]]; then
    RISK="PATCH_LEVEL_BEHIND"
    echo "[ALERT] $SERIAL ($MODEL): patch $PATCH < required $MIN_PATCH" >&2
  fi
  if [[ "$SIDELOAD" == "1" ]]; then
    RISK="${RISK}+SIDELOADING_ENABLED"
    echo "[ALERT] $SERIAL ($MODEL): unknown-sources installs ENABLED" >&2
  fi

  echo "$SERIAL,$MODEL,$AVER,$PATCH,$RISK,$SIDELOAD" >> "$OUTFILE"
done

echo ""
echo "[+] Audit complete: $OUTFILE"
echo "[+] Any PATCH_LEVEL_BEHIND device is unremediated for known-buggy builds —"
echo "    when Samsung ships the post-Pwn2Own bulletin, this list is your priority queue."

Remediation

The patches do not exist yet. Your remediation plan therefore has two phases — execute phase one today, and have phase two staged and ready.

Phase 1 — Now (embargo window, no patch available)

1. Reduce the mobile delivery surface on high-risk devices. For executives, board members, journalists, legal counsel, and anyone whose compromise would be an event: enable Lockdown Mode-equivalent hardening on Android — disable 2G at the modem level (Settings > Network > SIM > disable "Allow 2G" on supported builds), enforce Google Play's Advanced Protection Program on managed accounts, and block sideloading fleet-wide via MDM policy (install_non_market_apps = 0).
2. Enforce browser update velocity. Chromium renderer bugs are patched in Chrome stable channel updates that typically ship within days of disclosure. Verify auto-update is functioning — a browser "managed" into staleness is the single most common real-world exploitation enabler we see in IR. Flag any browser build more than 14 days behind stable for forced remediation.
3. Constrain WebView exposure. Inventory which enterprise apps render web content via WebView2 (Windows) / Android WebView. Every one of them inherits the full browser attack surface with none of the browser's UX warnings. Where feasible, disable link-in-app rendering and force external browser handling.
4. Deploy the behavioral detections above and route the browser-child-process rule to high-severity triage. This is durable coverage for the entire class of exploit chains demonstrated at Pwn2Own, not just these 32 bugs.
5. Stage your patch pipeline. Pre-approve emergency change windows for the Samsung security bulletin and Chrome stable releases expected in the coming weeks. The organizations that suffer in post-Pwn2Own patch waves are the ones whose change boards treat a KEV-worthy browser RCE like a routine monthly patch.

Phase 2 — When vendor patches ship (expected within ZDI's ~90-day disclosure window)

1. Monitor the primary sources: the Samsung Mobile Security Bulletin (security.samsungmobile.com), Google Chrome stable channel release notes (chromereleases.googleblog.com), and the ZDI upcoming-advisories page (zerodayinitiative.com/advisories/upcoming). CVE assignments for these bugs will appear there first.
2. Watch CISA KEV. Pwn2Own-derived vulnerabilities have been added to KEV rapidly after disclosure in recent cycles. A KEV listing carries a federal remediation deadline (typically 21 days for FCEB agencies) — treat it as your SLA even in the private sector.
3. Deploy by risk tier, not by convenience. Tier 1 (patch within 72 hours): internet-facing browsers on all endpoints, mobile devices of high-target individuals. Tier 2 (7 days): remainder of browser fleet. Tier 3 (14 days): everything else. Use the ADB audit script above to validate Android patch-level compliance post-deployment — MDM "success" reports and actual ro.build.version.security_patch values diverge more often than vendors admit.
4. Retrospective hunt. Once CVE details publish, run the Sigma/KQL content above back across your retention window. The embargo period is also a period during which a parallel actor may have found and used the same bugs — assume compromise logic applies to your highest-value mobile users.

The strategic takeaway

Thirty-two zero-days in one day is not an anomaly — it is the market clearing price of modern software complexity, demonstrated on a stage. The organizations that come out ahead of events like Pwn2Own Ireland are not the ones with the best signatures; they are the ones with behavioral detection depth, sub-week patch velocity on browser and mobile targets, and hardening that assumes the fully patched device can be taken. Build for the class, not the CVE.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub