CISO Tribune

Town Square · Thursday, October 29, 2026

Leaked data on 40,000-plus DHS staff and 5 more

By Hadass Liza Bitton · October 29, 2026 · 6 stories · opinion, marked as ours

The community's main argument today was over the leak site that published data on more than 40,000 Department of Homeland Security (DHS) staff: DHS says it is aware of a potential breach and Reuters matched leaked records to real employees, but how the data was taken is not established and Okta denies any compromise. Two other widely shared claims hold up less well: Dream's account that a chained PHP2Shell attack rooted 25 servers rests on its own blog post, and the viral warning that Discord will make old public server messages searchable is contradicted by reporting that posts from before the mid-December launch are excluded. In our view, the stories that should change a security checklist this week are Alpine Linux's finding that a GitLab upgrade left CVE-2026-97229 open on its custom Ruby image, and Eye Security's warning that revoking Microsoft 365 sessions may not stop attackers reading mail through application programming interfaces (APIs), where Microsoft's documentation confirms revocation can lag behind token lifetime.

Today's board

  1. 1Leak site publishes data on 40,000-plus DHS staff; DHS cites potential breachPartly confirmed
  2. 2Alpine Linux says GitLab upgrade left CVE-2026-97229 open on its custom Ruby imageConfirmed
  3. 3Dream says chained PHP2Shell attack rooted 25 servers; the campaign is unverifiedNot confirmed yet
  4. 4Discord will make some public server messages searchable on the web from DecemberPartly confirmed
  5. 5Eye Security: revoking M365 sessions may not stop attackers reading mail via APIsPartly confirmed
  6. 6Orange Tsai publishes Edge full chain built only from logic bugs, patched since MayConfirmed

Story 1

Leak site publishes data on 40,000-plus DHS staff; DHS cites potential breach

Outlets confirm the release and partial authenticity. How the data was taken, and whether Okta was involved, is not established.

Our verdictPartly confirmed

DHS told Wired it is aware of a potential breach and Reuters matched leaked records to real employees, but Okta denies any compromise and the full trove is unverified.

Where it was argued

What people are saying

Wired reported that a leak of Department of Homeland Security (DHS) records exposed details of more than 41,000 employees or contractors. Wired said the records include sensitive information on undercover and surveillance programs. Reuters reported that the transparency group Distributed Denial of Secrets (DDoSecrets) says the leak covers more than 40,000 DHS employees. On Hacker News the debate ran across several threads, and commenters pointed readers to the main discussion. A post on Bluesky said the platform is blocking links to the archive and cited the contact information inside it.

What holds up

DHS has acknowledged the incident without confirming its scope. A spokesperson told Wired the department is aware of a potential breach and is working to address it.

Reuters could not verify the whole trove. Wired said the records were last updated on August 19, 2026. They include email addresses, phone numbers and office addresses, plus references to internal systems.

The breakdown supports commenters who said the leak reaches beyond immigration enforcement. Wired counted nearly 1,000 records tied to the Cybersecurity and Infrastructure Security Agency (CISA), and more than half of those are contractors. The counts differ by outlet. NPR put Immigration and Customs Enforcement (ICE) and its Homeland Security Investigations (HSI) unit at 10,000 records. The BBC reported nearly 6,600 ICE staff. Wired found 39 HSI employees in permission groups whose names include an abbreviation that court filings say stands for certified undercover operation.

How the data was taken is not established. DDoSecrets says it came from DHS's Okta login system. NPR reported that the hackers said they subverted DHS's single sign-on (SSO) system. Okta told Wired it has no evidence its data or systems were compromised.

Our verdict is partly confirmed. The publication is real and DHS calls it a potential breach. The authenticity of the full trove, the exact counts and the access path all remain open.

Inside the threads

One commenter who said they know people named in the leak warned about staff whose duties are far from ICE. Another said undercover personnel may now be in real danger. A reply asked why anyone assumes hostile actors did not already hold the data. In a separate thread, commenters argued over whether publishing work contact details counts as doxxing at all. The most practical point described SSO and mobile device management (MDM) services as an "extremely major single point of failure." That argument assumes an access path that Okta denies.

Our take

In our reading, the lasting lesson concerns directory data more than any single vendor. Wired said the leak provides a map of how DHS is organized and how it operates. We think most organizations name access groups after programs, tools and sensitive projects. Any account that can read the directory can often read those names too. A national security expert at Recorded Future told Wired the dataset gains value when it is correlated with previously compromised and commercial data. We agree that this is the underrated risk: tailored phishing and impersonation aimed at staff in every unit, including those outside the headlines. We think the claim that the Okta platform was breached is overblown until evidence appears.

What to do

  • Review your identity provider's group names as if they had already leaked. Move sensitive program names out of labels that ordinary users can read.

  • Limit which accounts and applications can enumerate the directory. Alert on bulk directory reads.

  • Brief staff in sensitive roles on targeted social engineering before anyone else contacts them.

What the verdict rests on (4 sources)

Story 2

Alpine Linux says GitLab upgrade left CVE-2026-97229 open on its custom Ruby image

An attacker targeted Alpine's GitLab. Upgrading did not close the flaw, because the fix ships as patched Ruby inside GitLab's official packages.

Our verdictConfirmed

Alpine Linux, the affected organization, describes the attempt and the patching gap, and Ruby's own advisory confirms the fix lived in GitLab's bundled Ruby.

Where it was argued

What people are saying

Alpine Linux published an incident report saying an attacker tried to exploit CVE-2026-97229 on its GitLab instance on October 20 and 21. The detail that spread: upgrading GitLab did not close the hole, because the fix is a patched Ruby that GitLab bundles in its own packages. The post drew 107 comments on Hacker News and was also discussed on Lobsters.

What holds up

The National Vulnerability Database entry gives the flaw a base score of 10, critical. It says an unauthenticated user could execute arbitrary code on a GitLab server through a crafted regular expression in a CI/CD configuration.

Alpine says a newly registered account sent crafted CI configurations while its instance still ran 19.3.4, without the October 12 fix. Its timeline says it had upgraded to 19.3.4 instead of 19.3.5 by mistake on October 13.

Alpine upgraded to 19.3.6 on October 22 and found the instance still vulnerable on October 26. It says GitLab's fix is a set of patches to the Ruby bundled in GitLab's own packages and container images, and Alpine's image used standard Ruby. Ruby's advisory says GitLab addressed these issues by patching the Ruby it ships. Upstream Ruby shipped the fix on October 23, in 3.3.13, 3.4.12 and 4.0.9.

Alpine found no evidence the attack succeeded but cannot rule it out, so it rebuilt the instance and reset all passwords. It says the aports repository, packages and the October 21 releases were not tampered with. Its signing keys have never been stored on the GitLab server.

The verdict is confirmed, by the affected organization and by Ruby's advisory. Whether the attacker got in is not established.

Inside the threads

Commenters on both sites praised Alpine for rebuilding and treating the server as compromised. The most practical Hacker News point was that "a version scan would have called that 19.3.6 image fixed," since the CVE is filed against GitLab and Ruby shipped its fix without requesting a CVE. Another commenter argued for pinning images to a specific digest and getting notified on changes, after Alpine re-published a fixed image under the same 19.3.6 tag. One Lobsters commenter said Ruby's patches landed two days after GitLab announced the CVE. Alpine's timeline puts the CVE on October 13 and Ruby's fix on October 23.

Our take

We think the lesson is less about this CVE than about where a fix lives. A vendor advisory keyed to a product version can hide a dependency fix that exists only in the vendor's own build. In our reading, any team that repackages vendor software owns that gap, and scanners keyed to product versions will not close it. We would treat this as a possible compromise, as Alpine did, not a failed attempt. We also think one detail is underrated: Alpine had no logging of outbound network connections, which is why the question stays open. Teams that run developer platforms on the internet should check whether they could answer it.

What to do

  • Inventory GitLab instances not installed from GitLab's official packages, and confirm they run Ruby 3.3.13, 3.4.12, 4.0.9 or later.
  • If you use the alpinelinux/gitlab image, pull 19.3.6 again; Alpine says any 19.3.6 image pulled before October 27 is vulnerable.
  • Ask your vulnerability management team whether scans check the Ruby inside self-built images, and pin images by digest so silent rebuilds show up.
  • For in-house Ruby apps, find any code that compiles regular expressions from user input and upgrade Ruby.
What the verdict rests on (4 sources)

Story 3

Dream says chained PHP2Shell attack rooted 25 servers; the campaign is unverified

CISA confirms the PHP2Shell flaws are being exploited. The 25-server campaign, including US government victims, rests on Dream's account alone.

Our verdictNot confirmed yet

Only Dream's own blog post describes the 25-server campaign; CISA's KEV listing confirms PHP2Shell exploitation in general, not this campaign.

Where it was argued

What people are saying

Security company Dream published a blog post saying it uncovered artifacts of what appeared to be a Chinese AI-assisted campaign that rooted 25 servers, including systems in a US government-affiliated environment. Dream says the attacker paired the PHP2Shell flaws with a kernel privilege-escalation exploit tracked as CVE-2026-46300.

The claim spread to Hacker News, where commenters asked whether the attack works against patched systems. On X, one post said hackers combined PHP2Shell with a Linux kernel exploit to gain root access on 25 servers.

What holds up

Exploitation of PHP2Shell itself is established. The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on October 26.

The Hacker News reported that the listing followed confirmed remote code execution against honeypot systems on October 24. That evidence came from Adel Karimi, detection and response lead at Perplexity. Karimi said the evidence covered an intentionally favorable single-worker mod_php setup and did not measure reliability on other configurations.

Federal agencies have until October 29 to patch. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Dream says it is withholding the name of the firewall vendor and the affected versions, and that it has notified the vendor. It says the 25 servers were in the United States, Japan, Taiwan and South Korea. It also says the recovered artifacts confirm credential extraction and directory enumeration. Dream says the work came from threat hunting with its own autonomous research product.

Our verdict: the 25-server campaign rests on Dream's account alone, so we rate the core claim unconfirmed. The exploitation of the flaws it describes is not in doubt.

Inside the threads

On whether patched servers are at risk, one commenter answered that the firewall software in Dream's report runs an unpatched version of PHP. Another argued that the flaw triggers before any application code runs, so secure application code offers no protection. Others pushed back on the alarm, saying most assessments they had seen called it "bad but clumsy."

One commenter's practical point was that a firewall's administrative PHP page should never be reachable from the internet and belongs on a management network. Part of the thread turned to the company's founders rather than to the technical evidence.

Our take

We think Dream's post should not change your patch priority, because the KEV listing already put these flaws at the top. The unverified parts are the scale, the attribution and the government victims. Treat those as one company's claim until a victim, the firewall vendor or an agency says otherwise.

What we think is underrated is the appliance angle. CISA notes that PHP is often a component of other software and may not be directly visible. Censys estimates that more than 32.51 million PHP services still run an affected version.

Dream's path from an exposed management interface to directory credentials is the scenario to plan for, whether or not this campaign is real.

What to do

  • Inventory every system running PHP, including appliances and vendor products where it is embedded, and patch internet-facing systems first.
  • Check advisories from your firewall, virtual private network (VPN) and appliance vendors. The flaws prompted numerous advisories from software and security vendors.
  • Move appliance management interfaces off the internet and onto a dedicated management network.
  • Monitor for PHP worker processes launching shells or downloading tools, as CISA advises. If an exposed appliance was compromised, review the directory credentials it could reach.
What the verdict rests on (3 sources)

Story 5

Eye Security: revoking M365 sessions may not stop attackers reading mail via APIs

Research says existing access tokens keep reading mail through APIs after session revocation or a password reset; only a disabled account blocks it.

Our verdictPartly confirmed

Microsoft's documentation confirms that revocation can lag behind token lifetime, but the finding that API clients keep reading mail rests on Eye Security's own testing.

Where it was argued

What people are saying

Eye Security published research on October 29 arguing that revoking a phished Microsoft 365 (M365) user's sessions does not stop an attacker who already holds tokens from reading mail. The post was shared to Reddit's r/blueteamsec. The discussion there was thin: one commenter asked whether anyone had seen attackers use mobile access to read mail after a phish.

What holds up

Microsoft's own guidance on revoking access says there can be a period between starting revocation and access actually ending. It also says access tokens from Entra ID last one hour by default.

Eye Security's tests go further. The researchers report that official Outlook clients lose access quickly after revocation, a password reset or a disabled account. They say access tokens still work for access through an application programming interface (API).

The post names the Graph API and the deprecated Exchange Web Services (EWS). It says Exchange ActiveSync also stays available.

According to the research, only disabling the account blocks all mail access. When the account is re-enabled, unexpired tokens work again. The post therefore advises keeping the account disabled for 90 minutes after the last access token was issued.

The research also reports that a token for a disabled account can still query users in Entra through Graph. It says there is currently no way to block that.

We rate this partly confirmed. Microsoft documents the revocation delay. The specific gap for API clients comes from Eye Security's testing.

Inside the threads

The Reddit discussion consisted of a single comment. The commenter said they had never seen an attacker use mobile access to read a user's email after a successful phish. That skepticism touches ActiveSync, the smartphone sync protocol. The research points to a different path: it says newer phishing kits are automated and use the Graph API to collect email. In our reading, nothing in the thread contradicts the findings.

Our take

We think the main lesson is for incident response runbooks. Many treat revoke sessions as containment, and this research suggests that step alone leaves mail readable by automated tools.

The exposure is not a new flaw. In our reading it follows from token lifetime, which the research puts at 60 to 90 minutes.

What we think is underrated is how much an automated kit can pull in that window. An hour of API access can be enough to copy a mailbox.

The lingering ability to query the directory also deserves attention, because it hands an attacker a map for the next phish.

Disabling an account locks a user out during a busy incident. We think that cost is worth paying.

What to do

  • Update account-takeover playbooks so the first step disables the account, not only revokes sessions. Microsoft's guidance includes clearing "Account enabled" in the user's properties. Keep the account disabled for at least 90 minutes after the last token was issued before re-enabling it.
  • During that window, review sign-in and mailbox audit logs for Graph, EWS and ActiveSync activity tied to the compromised user.
  • Restrict EWS and ActiveSync for users and apps that do not need them.
  • Treat directory information the attacker could query as exposed, and warn likely follow-on phishing targets.
What the verdict rests on (2 sources)

Story 6

Orange Tsai publishes Edge full chain built only from logic bugs, patched since May

The DEVCORE researcher's Pwn2Own Berlin chain escaped Edge's sandbox without memory corruption. Microsoft fixed the Edge bugs on May 15.

Our verdictConfirmed

The researcher's own write-up, which quotes the Zero Day Initiative's contest confirmation, is backed by independent reporting from The Hacker News, which also lists the CVEs and the fixed Edge version.

Where it was argued

What people are saying

Orange Tsai, a principal security researcher at DEVCORE, published a write-up of what he calls "a completely handmade, logic-only Microsoft Edge Full Chain." The headline point spreading with it is that the chain used no memory corruption at all. On Lobsters, commenters praised the research, and one criticized Microsoft's handling of it.

What holds up

The core claim is confirmed. The write-up quotes the Zero Day Initiative confirming that Tsai chained logic bugs into a sandbox escape on Edge at Pwn2Own Berlin 2026, earning $175,000. Tsai writes that the full chain is made up of five bugs and two Windows features.

The Hacker News reports that the chain can turn a malicious web page into code running outside Edge's sandbox. It says Microsoft shipped the fix on May 15 in Edge Stable version 148.0.3967.70, tracked as CVE-2026-45492, CVE-2026-45494 and CVE-2026-45495.

This was a contest exploit. The outlet found no evidence of use against real users and says the public CVE records list exploitation as none. The criticism of Microsoft's response does not hold up on speed: DEVCORE said the fix came within 24 hours of disclosure.

Inside the threads

The discussion was brief and admiring. One commenter said each bug looked significant even on its own. Another went further: "I think a UXSS is basically a critical by itself!" That commenter also said Microsoft did the wrong thing at every turn. In our reading, that remark is about the design choices the bugs exposed, not the patch timeline. The fix arrived the day after the contest.

Our take

We think the lesson here is about bug class, not this specific chain, which has been patched for five months. Much browser hardening spending targets memory corruption, and this chain went around those mitigations by abusing features working roughly as built. Those are exactly the features security teams tend to turn on and then stop examining.

The scoring is also underrated as a problem. A triage process that only looks at single CVE scores would have underweighted a chain that ends in code execution.

The overblown part is any sense of current exposure. Fleets on automatic updates received this fix long ago.

What to do

  • Confirm that no managed Edge installs are below version 148.0.3967.70, and find any machines where updates are blocked or deferred.
  • Watch the Edge security release notes. As of October 27, Microsoft says it is actively working on releasing a fix for recent Chromium security fixes.
  • Review Edge features enabled through policy, especially sign-in and convenience features, and turn off any you do not need.
  • When you triage browser advisories, weigh how bugs could combine instead of relying only on per-bug severity scores.
What the verdict rests on (4 sources)

How Town Square works

Every day we read what the security community is discussing on Hacker News, Reddit, Mastodon and Lobsters, and what search shows of the conversation on X. For each story we check the claim against primary sources, give a verdict, digest what the threads said, and say what we think. Every fact rests on a passage found word for word on a source page; our views are labelled as ours. We never name the people in a thread.

What each verdict means · How we work · Report a mistake

The CISO Tribune briefing

Every verified CISO move and one piece of analysis, weekly.

Unsubscribe any time. See the privacy policy.