#0day

Read Time:3 Minute, 41 Second

The first day of Pwn2Own Ireland 2026 delivered a reminder that even the newest flagship hardware and the latest generation of AI-connected services remain full of unknown security holes. Trend Micro’s Zero Day Initiative (ZDI), which runs the contest, confirmed that competing teams successfully demonstrated 32 unique zero-day vulnerabilities on October 6, 2026, earning a combined $388,500 in payouts across 21 recognized entries.

Flagship Phones Split Between Falls and SurvivalsSamsung’s new Galaxy S26 was the day’s most popular target, and it did not escape unscathed. Three separate teams successfully compromised the device, each chaining four bugs together. Vietnam’s Viettel Cyber Security led the pack, earning $31,250 for a chain that combined one freshly discovered flaw with three bugs Samsung already knew about. Interrupt Labs followed with $15,750 for a single new vulnerability plus three “collisions” — bugs independently found by more than one team, which reduces the payout even though ZDI still credits the working exploit. Ikotas Labs rounded out the Galaxy S26 results with $11,000 for three new bugs and one previously unpatched issue.

Google’s Pixel 10 fared better, at least on paper. A team from White Noise Club ran out of time before completing their exploit chain against the device. ZDI was careful to note that a failed attempt under contest time pressure doesn’t mean the phone is free of exploitable issues — it simply means this particular chain wasn’t finished in the allotted window.

AI Services Prove Just as Breakable as Traditional SoftwareTwo of the day’s targets reflected how deeply AI tooling has now been folded into the contest’s scope. OpenAI’s Codex coding assistant fell to a single argument-injection flaw from Ikotas Labs, worth $40,000 — one of the day’s largest single payouts, though ZDI withheld technical specifics pending a fix. LiteLLM, a popular open-source gateway used to route calls to large language models, was hit twice: researcher Taisic Yun of Xint earned $40,000 by pairing improper input validation with code injection to pop a reverse shell, while a second team, Out of Bounds, chained four bugs (two previously known) for an additional $15,000.

Oracle’s Autonomous AI Database also went down, with VinSOC stringing together five separate flaws for a $40,000 payout — the same team’s attempt against the Chroma vector database ran out of time before completion.

Smart Home and Connected Devices Add UpConsumer hardware outside the phone category contributed heavily to the day’s zero-day count. VinSOC researchers Vũ Chí Thành and Huỳnh Đức Tin disclosed seven distinct zero-days in the Philips Hue Bridge Pro alone, worth $40,000, while other attempts against the same hub largely reused already-known issues. Sonos’ Era 300 speaker fell to McCaulay Hudson, who combined an out-of-bounds write with a format-string vulnerability for $50,000 — the single richest reward of the day. Garmin’s Index BPM smart scale yielded $20,000 for Interrupt Labs via a combined out-of-bounds read and write, and Lexmark’s CX532adwe printer was separately compromised by Team Confused’s Thanh Do and by Sina Kheirkhah of Summoning Team, though no payout figures were disclosed for those entries.

Why the Scorecard MattersAcross the vulnerability classes involved — argument injection, input validation failures, code injection, and memory-safety bugs like out-of-bounds reads, writes, and format-string errors — the common thread is how ordinary these bug types are, even in products built by well-resourced vendors in 2026. ZDI’s contest rules require vendors to be notified immediately and given a fixed window to patch before any technical detail becomes public, which is why none of Wednesday’s winning chains come with proof-of-concept code attached.

That disclosure process is also the central safety valve here: nothing demonstrated at Pwn2Own has been seen used against real users, and the contest format exists specifically to get these bugs into vendors’ hands before criminal groups find them independently. Still, the sheer volume — 32 unique issues in a single day, spanning phones, AI infrastructure, and smart-home devices — is a useful gut check for any organization that assumes its newest hardware or its AI vendor’s gateway is inherently hardened. ZDI has indicated further results will be published as the remaining two days of the contest conclude, and security teams running any of the affected products should watch vendor advisories closely in the weeks ahead for the patches these findings will eventually produce.

Read Time:4 Minute, 32 Second

Just weeks after Citrix shipped an emergency patch for two zero-day vulnerabilities under active attack, administrators who installed the fix are running into a new headache: their NetScaler appliances keep rebooting on their own. The pattern has been widely reported on system administrator forums, and Citrix has confirmed it is investigating, though the company is careful to note that the crashes do not, so far, indicate the original zero-days have resurfaced.

A Fix That Introduced a New CrashThe appliance behind the trouble is build 14.1-73.37, the version Citrix released to close CVE-2026-88771 and CVE-2026-88772. The first of those flaws was serious enough on its own: it let an unauthenticated attacker execute commands on vulnerable NetScaler deployments with no credentials required. The second could be triggered when DTLS was enabled, opening the door to either remote code execution or a denial-of-service condition. Citrix confirmed that both bugs had already been exploited in the wild against appliances that had not yet been updated, which is what pushed so many organizations to patch quickly.

That urgency is now colliding with a separate problem. According to reports from administrators and details Citrix has acknowledged, specially crafted SAML authentication requests are crashing nsaaad, the NetScaler process responsible for handling authentication. When the process dies, a watchdog component called pitboss steps in and forces the appliance to restart. One crash is an inconvenience; several administrators have described repeated cycles severe enough that they opened severity-one support cases with Citrix.

Not Proof the Zero-Days Are BackIt is tempting to read “NetScaler” and “crash loop” together and assume attackers have found a way around September’s patch. Citrix’s position is more measured: 14.1-73.37 remains its fixed release for CVE-2026-88771 and CVE-2026-88772, and the company says engineering and support teams are tracking a distinct, newly identified SAML-handling issue rather than a bypass of the original fixes. A crafted request that crashes nsaaad does not, by itself, hand an attacker control of the box — but a process that keeps failing on an internet-facing authentication gateway is still a real availability problem, and a dangerous one for organizations that route remote-access traffic through it.

One detail worth flagging for defenders: at least one administrator reported that routine vulnerability scanning was enough to trigger the crash pattern, which suggests the trigger condition may be broader than a narrowly targeted attack and could surface simply through normal network traffic or security tooling hitting the appliance.

Why High-Availability Pairs Are Especially ExposedNetScaler appliances are frequently deployed in high-availability pairs specifically to avoid single points of failure. That design assumption breaks down if both nodes in a pair receive the same malformed SAML traffic, or if a failover event hands the problem straight to the standby unit as it takes over. For organizations relying on NetScaler for VPN access, application delivery, or single sign-on, a HA pair that reboots in tandem effectively becomes a single point of failure again, just when it is needed most.

What Citrix Is Telling CustomersCitrix has published interim SAML deployment guidance directing customers to check whether the relevant SAML configuration is active on their appliances, review available mitigation options, and prepare to apply a corrected build once it is issued. As of this reporting, Citrix had not assigned a new CVE to the reboot issue, published full root-cause detail, or named a release number for the fix — all of which are expected to arrive in a forthcoming security bulletin.

Recommended Steps for AdministratorsConfirm the exact build running on every active and standby node against Citrix advisory CTX697096, which lists 14.1-73.37, 13.1-64.23, and the corresponding FIPS/NDcPP builds as the patched versions for the original zero-days.

Preserve core dump files, system logs, authentication records, and a full support bundle before another reboot overwrites evidence.

Correlate reboot timestamps against inbound SAML requests, firewall logs, and identity-provider logs to characterize the trigger.

Watch for nsaaad crash messages, unexpected files under /var/core, unfamiliar administrator sessions, and unusual outbound connections — artifacts that could point to activity predating the patch rather than the new crash bug.

Treat any temporary network-level blocking as a short-term bridge rather than a fix, since the traffic sources involved can change.

Keep severity-one cases open with Citrix and apply only vendor-sanctioned mitigation steps while the investigation continues.

That last point about pre-existing compromise is not theoretical. Earlier reporting on the September campaign against unpatched NetScaler devices described attackers obtaining root access, planting hidden web shells, and tunneling into internal networks before the zero-days were disclosed. Patching closes the original entry point, but it does nothing to remove access or tooling an attacker may have already planted. Organizations that were running vulnerable builds before the fix should treat this moment as a prompt to hunt for signs of prior compromise, not just confirm the patch installed cleanly.

Citrix has not given a firm timeline for the follow-up build. Until one ships, the practical advice for NetScaler operators is to stay on 14.1-73.37 or the other patched releases rather than rolling back, monitor affected appliances closely, and treat every unexplained reboot as both an availability incident and a potential security event worth investigating rather than dismissing as a glitch.