DEV Community: Etairos.ai

Stolen Passwords, No Alarms: How France's Tax Agency Lost Data on 600,000 Taxpayers and Businesses

Etairos.ai — Tue, 29 Sep 2026 20:04:37 +0000

TL;DR

what: An attacker used several dozen DGFIP staff passwords, probably stolen by infostealers, to scrape France's E-Contact taxpayer messaging tool in June and July without detection.
impact: Tax and contact data on a little over 350,000 individuals and 250,000 businesses was exposed, plus land-registry data on nearly 435,000 households through a second route.
fix: ANSSI's audit points to weak login protection, poor network separation and monitoring gaps, including password-only portals and a SOC that never watched ADER.
who: French taxpayers and businesses that used E-Contact, and any organization whose staff can reach internal portals with a password alone from devices it does not manage.

Several dozen stolen staff passwords, two portals that asked for nothing more, and a security operations center that reset the wrong door. That is how an attacker walked out of France's tax administration with data on a little over 350,000 individuals and a little over 250,000 businesses in June and July. Neither the DGFIP nor ANSSI, France's national cybersecurity agency, saw the data leave. The theft became known on August 12, when the attacker claimed it on an online forum, seven weeks after the first batch was taken.

The key line in ANSSI's report, published Tuesday, is its verdict: the attack was not sophisticated. That contradicts the ministry overseeing the DGFIP, which said in August that access checks had not revealed the theft "because of the sophistication of the attack." ANSSI, which Prime Minister Sébastien Lecornu asked for an in-depth audit, puts it down to weak login protection, poorly separated networks and gaps in monitoring. (Source: The Hacker News, reporting on the ANSSI report.)

What was taken

The data came from E-Contact, the tool taxpayers use to message the tax administration behind impots.gouv.fr. For individuals, the data that may have been viewed or copied includes tax ID, contact details, family situation, reference taxable income, tax withholding rate and a list of messages exchanged with the DGFIP. For fewer than 250 people, the messages themselves may also have been taken. For businesses it covers company name, SIREN registration number, address and basic message details. For fewer than 2,076 businesses, message content may have been seen. Taxpayers' own online accounts and passwords were not compromised.

A second route reached land-registry data through APEX, a portal for partners such as notaries and land surveyors that required a password and a one-time code sent by email. The DGFIP found that a land surveyor's computer at a private firm had possibly been compromised, which let the attacker bypass that code. That data was taken between July 27 and August 8 and concerns nearly 435,000 households, according to a September 4 Senate finance committee note reported by Public Sénat.

How the attacker got in

Credentials: several dozen DGFIP staff passwords, stolen over three months, probably by infostealers on computers the DGFIP did not manage, most likely staff's own devices.
Password-only portals: PIGP, used for email and HR services, and ADER, which provides access to DGFIP applications via the RIE, asked only for a password. A stolen one worked immediately.
Borrowed network access: the attacker reached the RIE, the network connecting French government ministries, through compromised Education ministry systems.
Flat segmentation: sensitive DGFIP applications could be reached from parts of the RIE that had no apparent need for them. Investigators found traces of many attempts to move into other government bodies.
Ordinary accounts: none of the accounts had special privileges, yet they could reach a large amount of data. ANSSI did not examine how user rights were managed in this report.

⚠️ The reset that left the session open — On June 23 a threat intelligence provider flagged an account, and a SOC ticket opened at 8:50 p.m. Paris time. At 4:26 a.m. the attacker began scraping E-Contact through ADER. The SOC handled the ticket at 10:40 a.m. by resetting the password. That resolved the PIGP alert but did not end the attacker's open ADER session. Data kept flowing for almost 16 more hours, until 2:31 a.m. on June 25.

Why no one saw it

The DGFIP already had a routine for stolen logins: when the SOC detected a compromised account or a provider flagged one, it reset the password. That routine fired several times. On June 7, searches from a stolen account triggered an alert and a same-day reset, but the SOC missed the attacker's move from PIGP to ADER. In July it happened again. The attacker restarted automated extraction on July 22 with another stolen account. The SOC spotted suspicious searches the next day and reset the account on July 24.

The SOC was not monitoring ADER at all. Nothing linked the warning signs: night logins, VPN connections, addresses in India, addresses known to be malicious. The 11 GB exchanged between June 22 and 25 raised no alert. Per-user request counts were not checked, even though scraping takes one request per page. ANSSI acknowledges that each signal alone usually produces many false alarms, but says that together they could have raised an alert.

ANSSI's own monitoring missed the theft too. Its sensors sit only at the entry and exit points of the RIE and the internet, and it has no access to application logs. Because the traffic came from real staff accounts, it looked legitimate. The agency still says the total request volume should have raised alerts. On June 9, the Education ministry's security team sent 17 indicators of compromise to all ministries. The attacker had already used one of those addresses and used it again in late June.

The RedEye take

The DGFIP did not have a detection problem. It had a response problem. Its alerts fired at least three times across June and July, and each time the result was a password ticket instead of an intrusion investigation. A password reset is account housekeeping. It does not contain an intrusion. When nearly 14 hours pass between a ticket and a reset, and the reset leaves the live session running, the attacker decides how long the incident lasts.

The second lesson is about who controls the perimeter. Here it was set by machines the DGFIP did not own: staff personal devices carrying infostealers, a private surveyor's laptop, another ministry's network. The August claim of sophistication did not hold up against the audit. Public bodies that explain a breach before it has been investigated put their credibility at risk. The open question is the one ANSSI left out of scope: why accounts with no special privileges could reach this much data.

What defenders should learn

A credential alert is an intrusion until proven otherwise. The response has to cover every application the account can reach, including sessions that are already open. In this case, one reset left ADER pulling data for almost 16 hours.
Coverage gaps matter more than detection rules. The SOC watched PIGP and did not watch ADER at all. A current map of which authentication points feed the SOC is worth more than another alert.
Correlate weak signals for each identity. Night logins, VPN egress, unusual geography and request volume are noisy alone. Together, according to ANSSI, they should have caught an 11 GB scrape.
Password-only portals assume every device holding the password is clean. Infostealers on unmanaged personal machines supplied several dozen working credentials, and the emailed code on APEX did not survive a compromised partner endpoint.
Indicators shared by peers lose value quickly. The 17 indicators arrived June 9, and the attacker reused one of the listed addresses weeks later. How fast a SOC takes in and acts on peer intelligence is something it can measure and improve.

Originally published on RedEye Threat Intelligence.

Keio Ransomware Attack Hits Hotel and Payment Systems at Tokyo Rail Operator

Etairos.ai — Tue, 29 Sep 2026 14:04:22 +0000

TL;DR

what: Keio Corporation, a major private railway operator in Tokyo, confirmed ransomware on its group servers on September 26, 2026, and shut down its network to contain it.
impact: Payment systems and the hospitality business behind 25 hotels were disrupted, and Keio is still checking whether customer or business partner data was accessed.
fix: Keio isolated its network, reported the incident to police and brought in outside experts to trace how the attackers got in; no vendor patch or CVE has been named.
who: Transit and hospitality operators running shared corporate IT, plus Keio hotel guests and business partners whose data may have been on the affected servers.

Keio Corporation, one of the big private railway operators serving Tokyo, has confirmed a ransomware attack on its group servers. The company found the intrusion in the early hours of Saturday, September 26, 2026, and shut down its network to stop further damage. Early reporting says the attack hit the hospitality business and disrupted payment systems. Train operations do not appear to be affected. No ransomware group has claimed the attack as of September 28.

Keio runs 85 km of track across 69 stations, has more than 2,200 employees and brings in about $2.6 billion a year. Its hospitality division runs 25 hotels. That mix of regulated transit and consumer hospitality on the same corporate network is what makes this incident worth studying.

What Keio Has Confirmed

Keio's public statement is short: "In the early hours of September 26, 2026, we confirmed a ransomware attack on our group's servers. We have reported the incident to the police and are conducting an investigation into the attack's route and damage with the cooperation of external experts."

Several things are still unknown. Keio has not said how the attackers got in, which ransomware family was used, how long they were inside before encryption, or whether data was stolen before the payload ran. The company says it is investigating whether customer or business partner information was accessed. Leaving that question open means Keio has not ruled out data theft.

Detection: early hours of Saturday, September 26, 2026
Containment: network shutdown across the affected environment
Confirmed impact: payment system disruption and possible delays on customer-facing services
Scope: hospitality side of the business, with no reported effect on train operations
Attribution: no claim from any ransomware group as of September 28
Response: police notified, external incident response experts engaged

Why the Weekend Timing Matters

Ransomware crews routinely start encryption late on Friday or early on Saturday. Security teams are thinner, change windows are quieter and a response takes longer to organize. By the time the incident is confirmed, encryption has often already spread across whatever the compromised accounts could reach.

Keio detected the attack within hours and chose a full network shutdown. That is the costly but defensible call: it trades customer-facing uptime, including payments, for a hard stop on lateral movement. The payment disruption and service delays are the direct cost of that choice, and they are much smaller than what an encrypted operational environment would cost.

⚠️ Assume data theft until proven otherwise — Almost every major ransomware operation now steals data before encrypting it and uses the stolen files as a second source of pressure. Keio has not confirmed exfiltration, but its open investigation into customer and partner data access fits that pattern. If a group claims the attack, a leak site listing would normally show up within days to weeks.

Rail Stayed Up: Segmentation Did Its Job

The most important detail in the reporting is what was not hit. Train operations appear to have kept running while the hospitality side went dark. For a critical infrastructure operator, that is exactly the result network segmentation is meant to produce: a compromise in the corporate or commercial zone does not reach the systems that move people.

That separation still needs to be verified. Keio has not published architecture details, and investigators have not finished tracing the attack path. Until they do, it is not clear whether the rail environment was out of reach by design, or whether the attackers simply went for the hotel and payment systems because those were the fastest route to pressure and payment. Hospitality networks are dense with payment terminals, booking platforms and guest data, and they tend to have many third-party connections and shared vendor access.

The Tokyo Metro Incident the Same Weekend

Tokyo Metro, a separate operator, disclosed its own cyber incident the same weekend, in which attackers accessed 59,000 member email addresses. No link between the two events has been established. The profiles are different: a ransomware attack with operational disruption at Keio, and what appears to be data access without encryption at Tokyo Metro.

Two Tokyo transit operators reporting incidents within the same few days is still worth watching. It may be coincidence, opportunistic targeting of one sector, or a shared supplier or common exposed technology. RedEye is not making an attribution call on the current evidence, and neither company has suggested a connection.

What we are watching for — A claim of responsibility and a leak site posting, Keio's findings on the initial access route, confirmation or denial of customer and partner data exposure, and any evidence of a supplier or technology shared by Keio and Tokyo Metro.

What This Means for Transit and Hospitality Operators

Critical infrastructure operators often run large commercial businesses next to their regulated operations: retail, real estate, hotels, parking and payments. Those businesses are usually managed as corporate IT, with a different risk tolerance from operational systems, yet they share identity infrastructure, domain trust, managed service providers and leadership attention with them. When ransomware hits the commercial side, the public still sees the brand as the rail company, and pressure on the business rises to match.

The Keio incident shows both sides of that. The core service appears to have been protected, but a single intrusion still cut payments and customer services across a hospitality business with 25 properties, and it opened a possible data exposure affecting guests and partners. For IT managers and security leaders, the question is not only whether operational systems are isolated. It is how much of the business can be stopped by one compromised corporate domain, and how quickly the organization can decide to take that domain offline.

RedEye Assessment

Keio's quick detection and decision to isolate its network appear to have limited the damage to commercial systems. The key unknowns are the initial access vector and whether data left the network. Those two facts will decide whether this ends as an operational disruption or becomes a long data breach notification process across Japan's hospitality customer base. RedEye Security helps critical infrastructure and hospitality organizations assess segmentation between commercial and operational environments, ransomware readiness and incident response decision paths. Contact RedEye for an assessment before the next weekend intrusion tests yours.

Originally published on RedEye Threat Intelligence.

A 'Reformed' Hacker's Arrest, and the ShinyHunters Rampage That Followed

Etairos.ai — Mon, 28 Sep 2026 20:04:14 +0000

TL;DR

what: Dutch police reportedly arrested convicted hacker Pepijn van der Stap on or around September 16, 2026, in connection with the ShinyHunters data theft and extortion investigation.
impact: In the days that followed, ShinyHunters claimed a breach of apply.fbijobs.gov that exposed Social Security numbers and personal data on more than 5,000 officials, and it has already stolen data on more than 6.2 million Dutch people from Odido.
fix: Oracle has patched CVE-2026-35273 in PeopleSoft, and the Mandiant WAF rules released as a stopgap were reportedly bypassed with URL encoding, so applying the vendor patch is the real mitigation.
who: Any organization running Oracle PeopleSoft for HR, benefits or payroll, particularly in higher education, technology, healthcare, agriculture, transportation and government.

On September 9, 2026, Pepijn van der Stap told KrebsOnSecurity he was a reformed hacker. He said he was paying restitution, dealing with civil lawsuits and trying to make a positive contribution to society. He was working as offensive security lead at the Dutch firm Neo Security. A week later, according to two sources with knowledge of the matter, Dutch authorities arrested him on or around September 16 on suspicion of aiding the data thefts and extortions of ShinyHunters, one of the most prolific extortion crews operating today. One source said a colleague saw authorities carting items out of his residence.

The group did not go quiet after the arrest. Within days, ShinyHunters claimed a breach of the FBI's job application site and publicly extorted the Russian ransomware group Cl0p. The story, reported by KrebsOnSecurity on September 28, 2026, involves a convicted criminal working in a trusted security role, a national telecom compromised by a single phone call, and a web application firewall rule that attackers encoded their way around.

A familiar double life

Van der Stap has done this before. In 2023, he was convicted over a string of data thefts and extortions that prosecutors said earned between €1.5 million and €2.7 million. At trial he described a Dr. Jekyll and Mr. Hyde existence. Under the handle "Umbreon" he extorted victims and posted their data on RaidForums and Breached, including a September 2021 listing covering 2.3 million people in the Netherlands. During the day he was a software engineer at Amsterdam-based security startup Hadrian and a volunteer at the Dutch Institute for Vulnerability Disclosure (DIVD).

He was sentenced to four years, one of them suspended, and released in December 2025. Nine months later, according to Krebs's sources, he is back in custody. He has not been charged in the reporting, and Neo Security did not respond to requests for comment. The facts that are established are serious on their own: a man with a confessed extortion history held an offensive security leadership role, and the Umbreon alias appeared throughout the imagery ShinyHunters used to publicize the FBI hack.

Odido: 6.2 million records from one phone call

Dutch police have been asking the public to help identify a voice. In a recorded February 2026 call, a native Dutch-speaking ShinyHunters member talked an employee of Odido, the country's largest mobile carrier, into logging in to a spoofed website. The attackers used that access to steal data on more than 6.2 million Dutch people. ShinyHunters confirmed to NL Times that the caller is a member, said it had arranged a criminal defense lawyer, and called the Dutch police "useless." According to the reporting, it is still unclear whether police have tied the caller to a real identity.

⚠️ The bragging is part of the playbook — ShinyHunters promised publicly that it would carry out "another large-scale data theft in the Netherlands." A group that pledges financial and legal support to arrested members is telling recruits that the risk is covered. Expect its operational tempo to go up after an arrest.

The FBI breach and a WAF rule that didn't hold

ShinyHunters says it got into apply.fbijobs.gov by exploiting CVE-2026-35273, a vulnerability in Oracle PeopleSoft, the HR, benefits and payroll platform. 404 Media reported that the stolen data covers more than 5,000 officials, with Social Security numbers and job titles such as special agent, threat intake examiner and major cybercrimes unit. Reuters reviewed documents shared by the group and found psychiatric and medical files of FBI staff. The FBI confirmed the hack.

The timeline is the main lesson here. ShinyHunters reportedly began exploiting the flaw as a zero-day in June. Oracle shipped a fix quickly, and Mandiant published WAF rules for organizations that could not patch right away. BleepingComputer then reported that ShinyHunters bypassed those rules with a URL-encoding trick. On September 25, Mandiant and the Google Threat Intelligence Group confirmed mass exploitation across dozens of systems in higher education, technology, healthcare, agriculture, transportation and government.

The RedEye take

There are two failures in this story, and the industry is uncomfortable with both of them.

The first is about trust. Security gives people second chances, and it should. But a confessed extortionist who once ran a double life at a security startup ended up in an offensive security leadership role, with the access and tooling that role brings. Rehabilitation and hiring for privileged roles are separate questions. Employers who treat "reformed" as a settled fact, rather than a claim to check continuously, take on risk they cannot see.

The second is about compensating controls. A WAF signature does not fix a vulnerability. It buys time against the attackers who don't bother to adapt, and ShinyHunters did adapt. Any organization that deployed the Mandiant rules and then deprioritized the Oracle patch was protected on paper only. In our view, arrests of individual members will not slow this group much. It is well funded, loud and organized to replace people. Defenders should plan around its methods, not around the police calendar.

What defenders should learn

Treat a virtual patch as an expiring exception. Any WAF rule that stands in for a vendor fix needs an owner, a deadline and a documented date for the real patch. Encoding bypasses are routine for capable crews.
HR and payroll platforms hold your most sensitive data. The FBI leak included medical and psychiatric files. Put PeopleSoft and similar systems in the same exposure and monitoring tier as your identity provider, not with ordinary line-of-business apps.
Voice is still an initial access vector at national scale. Odido lost 6.2 million records to one call and one spoofed login page. Phishing-resistant authentication for employees who can reach customer data does more than awareness training.
Screening for privileged roles should continue after the hire. Offensive security staff hold credentials, tooling and client knowledge. Periodic re-review and separation of duties on client data are basic hygiene, not a sign of distrust.
Arrests can trigger escalation. When law enforcement moves against a group that targets your sector, raise monitoring for a while. ShinyHunters launched its most brazen attacks within days of the reported arrest.

Source — Reporting based on KrebsOnSecurity, "Dutch Police Arrest 'Reformed' Hacker in Shiny Hunters Investigation," September 28, 2026, which cites 404 Media, Reuters, BleepingComputer, NL Times and Mandiant/GTIG research.

RedEye Security can assess how exposed your HR and SaaS platforms are, how old your compensating controls are, and how well your privileged access holds up against a group like ShinyHunters. Contact us for an assessment.

Originally published on RedEye Threat Intelligence.

Russia's Hybrid War on Europe: Water, Energy and Drones Now Share One Playbook

Etairos.ai — Sun, 27 Sep 2026 20:04:57 +0000

TL;DR

what: Recorded Future's Insikt Group documents Russia running cyber sabotage, drone incursions and AI-generated disinformation against European states that back Ukraine.
impact: Water and wastewater systems in Norway and Poland and Polish energy infrastructure have already been hit, and drones have been flown near Estonia and Romania's Neptun Deep offshore gas facility.
fix: Enforce phishing-resistant MFA and harden internet-facing firewalls, VPNs, email and web portals, the initial access points Russian operators favor.
who: Critical infrastructure operators, plus logistics, dual-use and specialized equipment makers whose work supports Ukraine, face the highest targeting risk.

Russia is running a cyber and physical pressure campaign against Europe, and the targets are the systems people depend on every day. Recorded Future's Insikt Group links attacks on water and wastewater infrastructure in Norway and Poland, attacks on Polish energy infrastructure attributed to Russia-aligned actors, and drone incursions near Estonia and Romania to one doctrine. The pieces are not yet coordinated. Insikt assesses that Russia could turn them into a coordinated campaign over the next two years.

For defenders, the headline is not a new exploit. It is a shift in who gets targeted and why. Insikt's answer: proximity to Ukraine's war effort.

What Insikt Group documented

The report groups Russian activity in Europe into three categories that now run in parallel.

Cyber sabotage: intrusions into water and wastewater systems in Norway and Poland, and attacks on Poland's energy infrastructure attributed to Russia-aligned actors.
Physical probing: Russian drones violating NATO airspace near Estonia's border, and a Russian drone intercepted by Romania near the Neptun Deep offshore gas facility in the Black Sea. Other reporting cites alleged attempts to use drones and explosives against cargo infrastructure at a German airport.
Information operations: AI-generated disinformation that impersonates European media outlets to push false narratives.

The Gerbera drone referenced in the reporting is roughly 2 meters long, weighs about 18 kilograms and flies at around 160 km/h. It is cheap, expendable and built to test air defenses and response times, not to win a battle. Recon, not assault.

The doctrine behind it

Russian officials described this approach in 2013 as "New Generation Warfare." The goal is to test an adversary's defenses, degrade its infrastructure and create fear inside its government and population without a kinetic invasion. A tampered water system, a disrupted power asset and a drone over a gas platform each look minor alone. Taken together they measure how fast European states detect, attribute and respond, and whether the public loses confidence while that happens.

⚠️ The escalation window — Insikt describes current activity as disconnected elements. Its assessment is that Russia could escalate into a coordinated campaign within two years. Organizations that treat each incident as isolated will be planning for the wrong threat.

Who is actually at risk

Chelsea Cederbaum, senior threat intelligence analyst at Recorded Future, put the key risk metric plainly: a company's "proximity to providing material support to Ukraine's war effort." That widens the target set well beyond utilities.

Critical infrastructure operators: water, wastewater, energy, gas.
Logistics firms moving goods into or across Europe, including airport cargo operations.
Dual-use manufacturers whose products serve both civilian and defense customers.
Specialized equipment makers: subsea cable repair, marine navigation systems, industrial defense components.

If your company ships, builds or maintains anything that reaches Ukraine, directly or through a supplier, assume you are on the list. Mid-size suppliers are attractive precisely because they have less security staff than the utilities and defense primes they serve.

How the cyber side gets in

The initial access pattern is well known and still works. Russian operations prioritize internet-facing firewalls, VPN concentrators, email systems and web portals. Those edge devices are where credentials are phished, where unpatched appliances get exploited and where a single stolen session opens a path into IT and then into OT. Water and small energy operators often expose remote access for vendors and on-call staff, and that remote access is the bridge.

Recorded Future's top recommendation is phishing-resistant multifactor authentication. SMS codes and push approvals can be relayed or fatigued. FIDO2 security keys and platform passkeys bind the login to the real site and defeat the adversary-in-the-middle kits used against VPN and email portals.

What the report does not give — The public reporting names no CVE, no malware family and no patched version. The defensive guidance is control-level: hardened edge devices, phishing-resistant MFA and segmentation. The checks below are built around those controls, not a single vendor fix.

What to do this quarter

Inventory every internet-facing firewall, VPN, mail gateway and web portal. Patch or retire anything past vendor support.
Move admin and remote-access accounts to FIDO2 or passkeys first, then the rest of the workforce. Remove SMS as a fallback for privileged roles.
Confirm no OT protocol ports (Modbus 502, S7 102, DNP3 20000, EtherNet/IP 44818) answer from the internet or the corporate LAN.
Run a tabletop that combines a cyber intrusion with a physical event at the same site, such as a drone sighting during a SCADA outage. Hybrid means both teams need one playbook.
Map your Ukraine exposure: which customers, shipments and suppliers tie you to the war effort. That map is your threat model.

Bottom line

Russia is probing Europe's water, energy and logistics layers with low-cost tools and deniable actors. The campaign is not yet coordinated, and the defenses that matter are not exotic: locked-down edge devices, MFA that cannot be phished and OT networks that cannot be reached from the internet. Organizations that close those gaps now will be harder targets if the two-year escalation Insikt describes arrives.

Originally published on RedEye Threat Intelligence.

Two Unpatched Citrix NetScaler RCE Zero-Days Exploited in the Wild: No Patch, No IoCs, No Bulletin

Etairos.ai — Sun, 27 Sep 2026 14:04:33 +0000

TL;DR

what: watchTowr reported on September 26 that two unpatched remote code execution flaws in Citrix NetScaler ADC and NetScaler Gateway are being exploited in the wild, found during forensic investigations.
impact: NetScaler sits at the network edge handling VPN, remote access and authentication, so code execution there exposes stored secrets, certificates, user sessions and a pivot point into the internal network.
fix: No patch, workaround or IoC exists yet; Citrix fixes are expected early in the week of September 28, and until then operators must choose between isolating, powering off or accepting the risk, and should treat exposed appliances as possibly compromised.
who: Every organization running internet-facing NetScaler ADC or Gateway, including those already on the August 19 builds 14.1-73.32 and 13.1-63.21, since Citrix has not said which versions are affected.

Two remote code execution vulnerabilities in Citrix NetScaler ADC and NetScaler Gateway are being exploited in the wild with no patch available, according to security firm watchTowr. Citrix had not confirmed the flaws, issued a bulletin, or published a fix as of Sunday, September 27. There is no vendor workaround and no published indicators of compromise. Some administrators have already taken their appliances offline rather than wait.

NetScaler appliances terminate VPN sessions, broker remote access, balance load and authenticate users. Code execution on that box gives an attacker the credentials, session tokens, certificates and private keys that flow through it, plus a foothold inside the perimeter.

What watchTowr Said, and What It Did Not

watchTowr first posted on X on September 26 that it was responding to rumors of several unpatched NetScaler RCE vulnerabilities in the wild, adding: "While details are scarce, the information is credible." A follow-up at 22:19 UTC gave the fuller account: two vulnerabilities, both remote code execution, both unpatched, both exploited before any fix existed, both discovered during forensic investigations. It said Citrix communications and patches are expected early in the week of September 28 and directed further questions to Citrix.

watchTowr has published no technical evidence, named no victim and not said whose forensic investigations found the exploitation. The firm has a track record on this product: in August it showed that a NetScaler heap overflow Citrix patched in June could be turned into remote code execution.

⚠️ Not CVE-2026-19490 — These are new flaws. They are separate from the authentication bypass CVE-2026-19490, which Citrix fixed on August 19 and CISA added to the Known Exploited Vulnerabilities catalog on September 9. Being on the August builds (14.1-73.32 or 13.1-63.21) or newer does not mean you are safe: Citrix has not said whether those builds are affected.

Admins Are Pulling the Plug

Reports of shutdown advice appeared on Reddit the same day. An administrator on r/Citrix wrote that their IT supplier's security team phoned to advise shutting down their NetScalers immediately, without giving details. Others in the thread said their organizations had done the same. Where the suppliers' warning originated has not been established.

With no bulletin, the decision for every NetScaler owner right now comes down to three options: keep it online and accept the risk, isolate it, or power it off. The second decision is whether to treat it as already compromised. For any internet-facing appliance, the answer to that second question should be yes until you have evidence otherwise.

Patching Will Not Tell You If You Were Hit

Because exploitation happened before any fix existed, installing the patch closes the door but says nothing about who already walked through it. The precedent is recent. In 2025, after a NetScaler flaw was exploited as a zero-day against Dutch organizations, the Netherlands' National Cyber Security Center (NCSC-NL) warned that updating alone did not remove the risk, because attackers could retain access gained before the patch, and told administrators to run its check scripts.

Plan the patch window and the investigation as two separate jobs. Capture evidence before you patch, reboot or reimage, because each of those can destroy the artifacts you need.

Citrix's Existing Compromise Guidance

Citrix already publishes a playbook for a suspected NetScaler compromise. It applies here:

Preserve evidence first: snapshot VPX instances, pull logs held on remote syslog servers and NetScaler Console, generate a technical support bundle, and capture a core dump of the packet engine.
Isolate the appliance from the network.
Rotate every service account password and secret stored on the appliance, reset passwords for users who authenticated through it, and revoke its certificates and private keys.
Keep the management interface off the internet. In Citrix's words: "The NetScaler Management Services should never be exposed to the public internet."

The NCSC-NL 2025 check scripts cover a live appliance, core dumps and full NetScaler images. They have limits. The live-appliance README says the script looks for files that indicate compromise, is not specific to any one vulnerability, and carries no guarantee of effectiveness. The code was last updated in September 2025, so it will not know about artifacts unique to these new flaws. A clean result is a data point, not a clearance.

The 13.1 Problem

NetScaler 13.1 reached End of Maintenance on September 15, twelve days before this disclosure. Citrix has not said whether 13.1 will receive a fix. If you still run 13.1, start planning the move to 14.1 now: you may be forced to upgrade major versions under active exploitation, with no guarantee a 13.1 build is coming.

RedEye Assessment — The sourcing is thin: one vendor, no evidence, no victims, no CVE. It is also consistent with the last three years of NetScaler history, where edge appliance zero-days became mass exploitation within days of disclosure. Treat the absence of a bulletin as a reason to act early, not a reason to wait.

What to Do Before Monday

Inventory every NetScaler ADC and Gateway, including forgotten VPX instances in cloud tenants, and record the exact build of each.
Confirm the NSIP and management services are unreachable from the internet. Fix that today regardless of the zero-days.
Collect a tech support bundle and VPX snapshot from each internet-facing appliance now, while the evidence is intact.
Decide per appliance: isolate, power off, or keep online with elevated monitoring. Document who accepted the risk.
Stage credential rotation for service accounts, LDAP bind accounts and certificates stored on the appliance so it can run the moment you confirm or suspect compromise.
Watch Citrix's security bulletin page and the CISA KEV catalog for the advisory expected the week of September 28, and patch immediately when it lands, after evidence capture.

Originally published on RedEye Threat Intelligence.

WordPress CVE-2026-87902 Exploited the Same Day It Was Patched: pearcmd.php Turned Into a Web Shell Dropper

Etairos.ai — Sat, 26 Sep 2026 20:04:31 +0000

TL;DR

what: CVE-2026-87902 lets an unauthenticated attacker make WordPress get_page_template() include an arbitrary readable local .php file, and exploitation started within hours of the September 22 patch.
impact: Where the theme and server preconditions line up, attackers chain the include with pearcmd.php to write PHP into /tmp and /var/tmp and load a web shell uploader, giving full code execution as the web server user.
fix: Update to WordPress 7.1.2, 7.0.6, 6.9.9 or 6.8.10 now, then hunt for dropped PHP files in /tmp and /var/tmp.
who: WordPress sites with auto-updates disabled or delayed, running a theme with a top-level page-* directory, on servers where pearcmd.php is present and readable (the default path in many PHP builds and container images).

WordPress shipped a fix for CVE-2026-87902 on September 22, 2026. The first exploitation attempt was recorded at 11:49 a.m. UTC that same day. The flaw carries a CVSS score of 9.2 and allows an unauthenticated attacker to reach remote code execution on sites where two preconditions are met. By September 25, CISA had added it to the Known Exploited Vulnerabilities catalog and ordered Federal Civilian Executive Branch agencies to patch by September 28.

Auto-updates will close this on most WordPress installs without anyone touching them. The sites that stay exposed are the ones where auto-updates were turned off for change control, stability, or a managed host's own patch cadence. Those are often the business-critical ones.

What the Bug Does

According to the WordPress advisory, an unauthenticated attacker can make get_page_template() resolve a page template to a chosen readable local .php file outside the active theme directories. WordPress then includes that file. Local file inclusion of PHP is code execution if the attacker can find a file that does something useful when included, and PHP ships one.

Exploitation requires both of the following:

The active child or parent theme contains a top-level directory whose name starts with page- (for example, page-templates). This is a common layout for themes that organize custom page templates.
A local .php target file exists on the server and is readable by the web server account. The target seen in the wild is pearcmd.php, the PEAR command-line front end.

⚠️ Why pearcmd.php matters — pearcmd.php is a well-known local file inclusion gadget. When included through a web request, it can be driven to write attacker-controlled content to a file on disk. That turns a read-only include bug into arbitrary file write, and then into code execution. Observed requests targeted /usr/local/lib/php/pearcmd.php, the default location in many PHP builds, including common container images.

Observed Attack Chain

Previdian recorded 68 exploitation attempts against its honeypot network starting September 23, with traffic from a New Jersey IP address (104.194.9[.]227) and an Indonesia-based address. The requests follow a three-step pattern:

Include /usr/local/lib/php/pearcmd.php through the vulnerable template resolution path.
Use pearcmd.php to write a PHP file into /tmp/.
Include that file, which pulls a PHP upload script from raw.githubusercontent[.]com/MrG3P5/web-shell/refs/heads/main/uploader.php, giving the attacker a persistent way to upload further payloads.

Patchstack independently saw the same progression: early reconnaissance that included harmless core files to confirm the bug, followed by active exploitation using pearcmd.php to write PHP to disk. Patchstack observed arbitrary file writes with attacker-controlled PHP content in both /tmp and /var/tmp.

Indicators of Compromise

File names observed in /tmp and /var/tmp:

wp-pear-rce-flag.php
poc87902.php
luci_.php
zeta_.php

Source IP addresses linked to exploitation:

104.194.9[.]227
43.250.53[.]42
180.251.159[.]243
195.178.110[.]247
107.189.14[.]87
45.61.184[.]170
92.246.130[.]76

Treat the IP list as short-lived. Mass exploitation campaigns rotate infrastructure quickly. The file names, the pearcmd.php request pattern and PHP files appearing in world-writable temp directories are the durable signals.

How Likely Is Compromise

Previdian founder and CEO Ryan Dewhurst expects mass exploitation attempts but relatively few actual compromises, because WordPress auto-updates are on by default and the preconditions narrow the target set. That assessment is reasonable at internet scale. It does not help an individual organization whose site happens to meet both conditions. A theme with a page-templates directory is routine, and pearcmd.php is present by default on a large share of PHP installs. If auto-updates are disabled on your site, assume you are in the exposed population until you verify otherwise.

Patched does not mean clean — Exploitation began before most manual patch cycles could run. A site patched on September 23 or later may already have a dropped PHP file or uploaded web shell. Updating WordPress removes the entry point, not anything the attacker left behind. Audit /tmp, /var/tmp and the web root after patching.

What to Do Now

Update to WordPress 7.1.2, or the fixed release on your branch: 7.0.6, 6.9.9 or 6.8.10.
Confirm auto-updates for core security releases are enabled, or that your host has applied the update.
Check whether your active theme and parent theme contain a top-level page-* directory. This tells you whether you met the first precondition.
Check whether pearcmd.php exists and is readable by the web server user. If PEAR is not used on the web host, remove read access to it or move it out of the PHP include path as defense in depth.
Search /tmp and /var/tmp for .php files created on or after September 22 and review web server logs for requests referencing pearcmd.
Look for outbound connections from PHP worker processes to raw.githubusercontent.com. A web server fetching code from GitHub is rarely legitimate.
If you find a dropped file, treat the host as compromised: rotate WordPress admin, database and API credentials, and check for new admin users and modified plugin or theme files.

Federal agencies have until September 28. Everyone else should be on the same timeline or faster, since the exploit chain is public, simple and already automated.

Originally published on RedEye Threat Intelligence.

Kiteworks Tells Customers to Go Dark for 9 Hours on a Federal Tip

Etairos.ai — Sat, 26 Sep 2026 14:04:26 +0000

TL;DR

what: Kiteworks asked customers to shut down their systems for nine hours this weekend after federal intelligence authorities warned that a threat actor may target some Kiteworks systems.
impact: No compromise has been confirmed, but customers lose their secure file transfer service for the whole window, and the company has not named the agency, the actor, or the attack vector.
fix: Follow the shutdown window in the Kiteworks customer email and upgrade to release 9.5.1, which Kiteworks says addresses all known vulnerabilities.
who: Organizations running Kiteworks systems; Kiteworks says its subsidiaries Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai, and 123FormBuilder are not affected.

This weekend, Kiteworks asked its customers to do something vendors almost never ask: switch off the product for nine hours. The company, formerly known as Accellion, says federal intelligence authorities gave it credible threat intelligence that a threat actor may attempt to target some Kiteworks systems. It has not found a breach, identified a victim, or named a CVE. It has a warning, and it is asking customers to take an outage because of it.

For the security teams affected, this means a weekend change window they did not plan, a business service that goes offline, and a decision to make on limited information. For everyone else, the episode shows what happens when threat intelligence arrives before the exploit does.

What Kiteworks has said

Frank Balonis, Chief Information Security Officer at Kiteworks, described the action as precautionary: "Kiteworks received credible threat intelligence from federal intelligence authorities indicating that a threat actor may attempt to target some Kiteworks systems. Out of an abundance of caution, we notified customers directly and recommended a precautionary shutdown window while we continue to work through the matter with federal intelligence authorities."

The company says it has found no evidence that any customer system has been compromised, and describes the advisory as preventative rather than a response to a confirmed attack. Customers received an email listing the specific hours of the recommended nine-hour window. Kiteworks also says release 9.5.1 addresses all known vulnerabilities and recommends that customers apply it. According to the company, its subsidiaries Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai, and 123FormBuilder are not affected. German publication Heise first reported the story, and The Hacker News carried it on September 26, 2026.

⚠️ What is still unknown — Kiteworks has not said which agency alerted it, who the threat actor is, or which component or vulnerability the actor might target. Customers are being asked to act on a warning they cannot independently check. Plan for a known outage and assume the threat details will not be shared.

Why this vendor, and why it matters

This is not a vendor without history. In late 2020 and early 2021, the Clop threat actor, also tracked as UNC2546, exploited multiple zero-day vulnerabilities in the company's file transfer program to run a data theft and extortion campaign against high-profile organizations. Managed file transfer platforms concentrate sensitive documents from many business units, sit at the network edge, and are built to talk to outside parties. That makes them among the most valuable single targets in an enterprise.

When a federal agency warns a file transfer vendor, and the vendor responds by asking the whole customer base to go offline instead of just patching, it signals that the vendor is not sure the current patch covers whatever is coming. The source does not state this outright. It is the plain reading of a patch-plus-shutdown recommendation.

The RedEye take

Kiteworks made the right call, and the industry should say so. Vendors are usually rewarded for staying quiet and punished for sounding the alarm. A company that has been through a Clop campaign has every reason to downplay an unconfirmed tip. Instead, it contacted customers directly, gave them a defined window, and pointed to a specific release. That is how pre-emptive disclosure should work.

The gap is attribution and scope. "Some Kiteworks systems" leaves every customer to assume they are included. A warning with no actor, no vector, and no indicators puts the full cost of caution on customers and gives them nothing to hunt with. We understand that federal sources often restrict what can be shared. Even so, customers need at least one indicator or a targeting criterion to judge their own risk, and we expect Kiteworks to publish more once the window closes. Until then, treat this as a credible threat to your edge and follow the recommendation.

What defenders should learn

Keep a pre-approved outage plan for every internet-facing file transfer system. If you need a change board meeting to take it offline for nine hours on a Saturday, you are not ready for the next warning like this one.
Log inbound traffic to the system while it is offline. Once the service is down, anything still hitting its public IP on 443 is either a misconfigured partner or reconnaissance. Keep those source IPs, because this dark window is the cleanest baseline you will get.
Map what breaks when the transfer platform goes down: automated partner feeds, scheduled jobs, and integrations that retry and fail quietly. Then check after the window that nothing queued up and silently dropped data.
Patch and contain, not either one alone. The vendor recommends both 9.5.1 and the shutdown. Upgrading during the dark window means the system comes back already patched, instead of being re-exposed on the old build.
Hunt backward, not just forward. "No evidence of compromise" is the vendor's view across its fleet. Review your own appliance and proxy logs for the weeks before the tip, since an actor preparing an attack may already have probed your instance.

This weekend's checklist — Confirm you received the Kiteworks customer email with the exact hours. Verify the host is actually unreachable from the internet during the window. Upgrade to 9.5.1 before you bring it back. Keep firewall logs for the whole window.

Bottom line

A nine-hour outage costs something you can measure. A repeat of 2021 would cost far more. Kiteworks has asked customers to accept a small loss to avoid a possibly large one, based on intelligence they cannot see. Take the outage, patch during it, and use the quiet window to collect the evidence the vendor has not yet published.

Source: The Hacker News, "Kiteworks Urges Customers to Shut Down Systems for 9 Hours Over Possible Cyber Attack," September 26, 2026, first reported by Heise.

Originally published on RedEye Threat Intelligence.

Roundcube CVE-2026-48842: Pre-Auth SQL Injection in virtuser_query Now Exploited

Etairos.ai — Fri, 25 Sep 2026 20:04:44 +0000

TL;DR

what: The Canadian Cyber Centre reports active exploitation of CVE-2026-48842, a pre-auth SQL injection in the Roundcube Webmail virtuser_query plugin caused by a preg_replace() backslash escape bypass.
impact: An unauthenticated attacker can run arbitrary SQL against the Roundcube database backend, exposing mail account credentials and stored message data.
fix: Upgrade to Roundcube 1.6.16 or 1.7.1 (released May 2026), or disable the virtuser_query plugin until you can.
who: Organizations running Roundcube 1.6.x before 1.6.16 or 1.7.x before 1.7.1 with the virtuser_query plugin enabled, including hosting providers, universities and government mail.

A Roundcube Webmail bug patched four months ago is now being used in real attacks. The Canadian Centre for Cyber Security updated its advisory this week to say CVE-2026-48842 (CVSS 8.1) is being actively exploited in the wild, citing open-source reporting. The flaw is a pre-authentication SQL injection: no account, no session, no phishing step. If your Roundcube server runs an affected version with the virtuser_query plugin enabled, an attacker can reach your mail database from the login page.

What is affected

Roundcube Webmail 1.6.x before 1.6.16
Roundcube Webmail 1.7.x before 1.7.1
Only deployments that enable the virtuser_query plugin, which maps login names to mailbox identities through a SQL lookup
Fixed in 1.6.16 and 1.7.1, both released in May 2026

virtuser_query ships with Roundcube but is opt-in. It is common in hosting and multi-domain setups where the address a user types at login has to be resolved to a real mailbox or identity through a database table. That profile, many tenants behind one webmail front end, is also where a database dump does the most damage.

How the injection works

The plugin builds its lookup query by substituting the user-supplied login value into an administrator-defined SQL template. Before substitution, the input passes through a preg_replace() based escape routine. According to the advisory, attackers can defeat that routine with a crafted backslash sequence, so a quote character survives escaping and breaks out of the string literal. From there, the attacker appends arbitrary SQL.

Because the lookup runs while resolving the login name, it executes before any password check. SentinelOne summarized the result: unauthenticated attackers can inject SQL into Roundcube's database backend, potentially exposing mail account credentials and stored messages. What the attacker can read or write depends on the privileges of the database account Roundcube uses, which in many installs is broader than it needs to be.

⚠️ Exploitation is confirmed, details are not — The Cyber Centre has not published indicators, actor names, or payloads for this campaign. Treat any unpatched server with virtuser_query enabled as potentially compromised, not just exposed, and review it accordingly.

Exposure by the numbers

Shadowserver Foundation data shows more than 523,000 Roundcube instances reachable from the internet. As of September 23, 2026, it flagged 10 of them as vulnerable to this CVE. That small number reflects what can be fingerprinted remotely: whether virtuser_query is enabled is not visible from the outside, so the true count of exploitable hosts is unknown. The number to care about is your own, and the check below answers it in under a minute.

Why Roundcube keeps getting hit

Webmail is a direct line to an organization's correspondence, and Roundcube sits at the edge on hundreds of thousands of servers. That makes it a recurring target:

February 2026: CISA added CVE-2025-49113 and CVE-2025-68461, both Roundcube flaws, to its Known Exploited Vulnerabilities catalog.
July 2026: Proofpoint reported a suspected China-aligned actor, tracked as UNK_MassTraction, exploiting known Roundcube vulnerabilities to drop web shells and the VShell post-exploitation tool.
September 2026: CVE-2026-48842 confirmed exploited, four months after the fix shipped.

The pattern is consistent. Actors are not waiting for zero-days. They work the gap between release and deployment, and Roundcube installs are often left on a distribution package or a hand-installed tarball that nobody owns.

What to do now

Inventory every Roundcube install, including distro packages under /usr/share/roundcube and tarball installs under /var/www.
Confirm the version. Anything on 1.6.x below 1.6.16 or 1.7.x below 1.7.1 is in scope.
Check whether virtuser_query appears in the plugins array or config. If it does, that host is exploitable until patched.
Upgrade to 1.6.16 or 1.7.1. If you run a distro package, confirm your vendor has shipped or backported the fix before trusting the package version.
If you cannot upgrade today, remove virtuser_query from the plugins list and reload PHP. Logins that depend on the mapping will break, which is the right trade-off against a pre-auth database read.
Reduce the Roundcube database account to the privileges it needs, and keep it off any database that also holds other application data.

If the host was exposed — Rotate the Roundcube database credentials and the des_key in config.inc.php, force password resets for mailbox users on that host, and search the web root for files you did not deploy, given that prior Roundcube campaigns dropped web shells.

Bottom line

CVE-2026-48842 is narrow in scope, one opt-in plugin, but severe where it applies: unauthenticated database access on the server holding your mail. The patch has been out since May. If you run virtuser_query, patch or disable it today, then look back through your logs for the window you were exposed.

Originally published on RedEye Threat Intelligence.

Bitget Loses $351.6M After Attackers Spoof the Data Its Own Approval Process Trusted

Etairos.ai — Fri, 25 Sep 2026 14:04:34 +0000

TL;DR

what: Bitget says attackers compromised a critical backend system in its wallet infrastructure, used it to spoof transaction data, and triggered its own authorization process to move $351.6 million out of hot and warm wallets.
impact: ETH, XRP, BNB, AVAX, USDT and USDC were taken across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base, and withdrawals are suspended while the review runs.
fix: No patch applies: Bitget has brought in Mandiant and SlowMist, contacted chain foundations (some have frozen attacker addresses), and says no further unauthorized transfers are possible.
who: Any organization whose payment or signing approvals rely on transaction data from a backend system that an attacker could compromise, especially crypto custodians and exchanges.

At 18:31 UTC on September 24, 2026, Bitget's security systems flagged unauthorized transfers from what the exchange called "a limited number of hot wallets." By the next day the total was $351.6 million. Bitget's CEO, Gracy Chen, said the attack method was "highly consistent with known patterns of North Korean hacker organizations," based on IP behavior patterns and on-chain analysis.

The number is large. How it happened matters more. According to Chen, the attacker "compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process to move funds out." No private key was reported stolen and no signer was reported bribed. The approval process ran as designed and approved transactions built from false data.

What Bitget has confirmed

Bitget has disclosed more than many victims do in the first 24 hours, though it has not said how the attacker first got in. According to the exchange's public statements, reported by The Hacker News:

Losses total $351.6 million, drawn from hot and warm wallets. Bitget says cold wallets and "the overwhelming majority of platform assets" were not affected.
Affected assets are ETH, XRP, BNB, AVAX, USDT and USDC, spread across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base.
Customer balances remain accurate. Deposits and trading continue. Withdrawals are temporarily suspended pending a "comprehensive security review."
Mandiant and SlowMist are running a third-party investigation.
Bitget has contacted the foundations of every affected chain, and some have confirmed they froze attacker wallet addresses.
Bitget Wallet, the self-custodial product, runs on separate infrastructure and was not affected.
"The specific method of system intrusion remains under active investigation."

⚠️ The core failure mode — The approval process did not fail. It received forged inputs from a system it trusted and approved them. When the machine that describes a transaction can be compromised, the humans and policies that approve that description give you no protection.

The pattern around it

The Hacker News notes that the disclosure came about a week after SentinelOne attributed an attack on an India-based IT services company to TraderTraitor, a North Korea-linked group. TraderTraitor is best known for stealing $1.5 billion from Bybit and $292 million from KelpDAO's LayerZero bridge. Bitget has not named a specific group, and neither do we. Its own statement is limited to consistency with known North Korean patterns.

Even so, the pattern is clear. The most costly crypto thefts no longer rely on breaking cryptography. They go after the systems around the signing step: the backend that prepares transactions, the interface that displays them, and the vendors and IT providers that can reach both. The key stays safe while the attacker controls what it signs.

The RedEye take

Bitget handled several things well. It detected the theft and published a timestamp. It kept cold storage separate from the hot wallets, so most assets were outside the blast radius. It brought in outside responders quickly and worked with chain foundations to freeze funds. Other firms should copy that playbook.

The architecture still did what attackers wanted it to. A single compromised backend system was able to write the transaction data that the authorization process accepted as true, and that one component was enough to move $351.6 million. When an approval chain trusts upstream data it cannot verify independently, it only confirms that the data is internally consistent.

Most companies are not crypto exchanges, but the lesson applies well beyond crypto. Finance payment runs, ERP vendor-bank changes, CI/CD release approvals and privileged-access workflows are all approval chains that trust an upstream system to describe the action correctly. North Korean operators have shown repeatedly that they will spend months inside that upstream system for a single large payout. Ask of every high-value approval in your environment: where does the approver's view of the transaction come from, and what happens if that source lies?

What defenders should learn

Verify destinations out of band. The signer or policy engine should check every destination address against an allowlist held on separate infrastructure with separate admin credentials. If the backend that builds a transaction can also edit the allowlist, you have one control, not two.
Reconcile every outbound transfer with a source request. Each hot-wallet withdrawal should map to a ledger entry, a customer withdrawal ID or a treasury ticket that was created before signing. A signed transfer with no matching request should page someone right away, not show up in a daily report.
Cap the blast radius per time window, not per transaction. Spoofed data can pass per-transaction checks many times in a row. Hard velocity limits on hot and warm wallets, enforced at the signer rather than in the backend, set the worst-case loss before the attack starts.
Treat IT service providers as part of the wallet perimeter. The TraderTraitor activity SentinelOne reported targeted an IT services company. Map every vendor with network or admin reach into signing-adjacent systems and give that access the same review you give signers.
Prepare the freeze playbook in advance. Bitget got some attacker addresses frozen by contacting chain foundations. Keep pre-built contact lists and evidence templates for every chain you operate on, because every hour of delay moves more funds out of reach.

Quick test for any approval workflow — Pick your largest routine outbound action, such as a wire, a withdrawal or a production release. Trace which system produces the data the approver sees. If one compromised host could change both the action and its description, your approval control has a single point of failure.

What we still do not know

Bitget has not disclosed the initial access vector, which backend system was compromised, how long the attacker was inside, or how much of the $351.6 million has been frozen. These answers will decide whether other exchanges are exposed to the same technique. Watch for the Mandiant and SlowMist findings. Until they are published, assume the entry point is unknown and review the whole path from request to signature.

Source: The Hacker News, "Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise," Ravie Lakshmanan, September 25, 2026. https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html

Originally published on RedEye Threat Intelligence.

ShinyHunters Claims FBI Breach: An Extortion Crew Attacks the Agency That Told Victims Not to Pay

Etairos.ai — Thu, 24 Sep 2026 20:04:49 +0000

TL;DR

what: ShinyHunters claims it breached the FBI via an unpatched Oracle PeopleSoft zero-day on FBIJobs.gov and defaced the jobs site.
impact: The group says it holds about 2 TB covering agents and applicants across FBI PEGA, Medlink, FBIJOBS, HR, CJ and PHIRE, including medical records.
fix: No PeopleSoft pre-auth RCE zero-day has been published and no patch exists for it; patch the related CVE-2026-35273 per Oracle, cut internet exposure of PeopleSoft, and audit third-party OAuth and SaaS trust paths.
who: Any organization running internet-facing Oracle PeopleSoft, plus public-sector agencies and their third-party HR and recruiting providers.

On Tuesday, September 22, the cyber extortion group ShinyHunters posted a statement to its dark web site claiming it had compromised the U.S. Federal Bureau of Investigation. The group says it holds "very sensitive data on almost ALL FBI Agents and individuals who filed an application with the FBI for a job." If even part of that holds up, the people exposed are the ones whose identities matter most to keep quiet: serving agents, former staff, and applicants who handed a government portal their background in good faith.

The motive, by the group's own account, is not money. ShinyHunters says it went after the FBI because of a May 2026 public service announcement that detailed its targeting of Canvas, an online learning management system, and urged victims not to pay. An extortion crew is now attacking the agency that told its victims to stop paying. That is the story, and it should worry every defender who has ever made a public no-pay call.

What ShinyHunters claims

A ShinyHunters spokesperson told The Hacker News the stolen data runs to roughly 2 TB and touches FBI PEGA, Medlink, FBIJOBS, HR, CJ and PHIRE, with more internal services possibly affected. The group singled out Medlink, saying it contains medical information, prescriptions, medical discharges, clinic visits and diagnoses tied to agents.

On entry, a spokesperson told The Register the group used a new Oracle PeopleSoft zero-day to get remote code execution and deface the FBI jobs site with a "This site has been seized by ShinyHunters" banner. The site now shows a scheduled maintenance page. The claim was first reported by 404 Media.

⚠️ Claimed, not confirmed — No details of a PeopleSoft pre-authenticated RCE zero-day exist publicly. The 2 TB figure, the list of six services and the Medlink contents all come from the attackers. Treat them as claims until the FBI or a third party confirms them.

What the FBI has confirmed

Less, and carefully worded. The FBI told Reuters it is "aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating." In a post on X, the Bureau said the point of breach is still undetermined, meaning it could sit with a third party or inside the FBI enterprise, and that it is working with the third-party providers that support FBIJobs.gov to mitigate risk.

That third-party framing matters. A recruiting portal is exactly the kind of system that gets outsourced, integrated with HR back ends, and forgotten by the core security team until something breaks.

The PeopleSoft angle

The zero-day claim is unverified, but the pattern is not new. In June 2026, ShinyHunters weaponized a similar PeopleSoft flaw, CVE-2026-35273, to break into enterprise networks and extort victims. A group that has already monetized one PeopleSoft bug has every reason to keep hunting in the same codebase. Organizations running internet-facing PeopleSoft should assume they are on the target list whether or not this specific zero-day turns out to be real.

A brand, not a crew

The FBI claim lands days after ShinyHunters hijacked the leak site of the Clop ransomware crew and posted an 8-figure demand against it. The group also rejects any link to The Com collective, calling that label propaganda from the security industry, and blames impersonators for threats sent to journalists and researchers.

Etay Maor, VP of threat intelligence at Cato Networks, said the claim "should absolutely be taken seriously" and noted that while nation-state groups have hit law enforcement before, citing the 2015 OPM breach, a cybercrime brand publicly claiming an FBI compromise is different. He pointed to the September 23 timestamp on a post that surfaced September 22 in the U.S. as a possible, non-definitive hint of activity in Asia. He also described ShinyHunters as a brand that outlasts takedowns, arrests and forum seizures by recruiting new operators, with a recent playbook built on help-desk social engineering, malicious OAuth applications and stolen SaaS integration tokens.

The RedEye take

Take the claim seriously and the rhetoric not at all. The public argument about disinformation and brand reputation is a sales pitch aimed at future victims: ShinyHunters is telling the market that paying it is safe and that law enforcement guidance is wrong. The Clop hijack and the FBI post are the same move, status plays designed to make the brand look untouchable. The real risk sits below the noise. Whether the door was a PeopleSoft zero-day or a third-party provider, the target was an HR and recruiting system holding medical and identity data on people whose safety depends on it staying private. Most organizations run the same class of system with far less scrutiny than their production perimeter. That gap is the lesson, not the drama.

What defenders should learn

Put HR, recruiting and occupational health systems in the crown-jewel tier. Medlink shows that the most damaging data is often in back-office systems, not the ones the SOC watches most closely.
Map every third party that touches your applicant portal. The FBI still cannot say whether the breach sits with a provider or its own enterprise; you should be able to answer that for your own stack within an hour.
Treat public statements against an extortion group as a trigger for elevated monitoring. The FBI PSA in May preceded this attack; if you name a group publicly, harden and watch your exposed surfaces first.
Audit OAuth grants and SaaS integration tokens as rigorously as firewall rules. The group's recent playbook abuses trusted identity paths, not just perimeter bugs, so a clean vulnerability scan is not a clean bill of health.
Stop exposing PeopleSoft login pages directly to the internet. Two PeopleSoft attacks by the same group in one year is a strong signal to put those portals behind VPN, a zero trust proxy or at minimum a strict WAF policy.

Source — Reporting based on The Hacker News, "ShinyHunters Claims FBI Breach, Says It Stole Data on Agents and Job Applicants," by Ravie Lakshmanan, September 23, 2026: https://thehackernews.com/2026/09/shinyhunters-claims-fbi-breach-says-it.html

Originally published on RedEye Threat Intelligence.

F5 BIG-IP APM OAuth Servers Under Active Attack: CVE-2026-94127 Gives Unauthenticated RCE

Etairos.ai — Wed, 23 Sep 2026 14:05:17 +0000

TL;DR

what: F5 disclosed CVE-2026-94127 on September 22, a heap-based buffer overflow in BIG-IP Access Policy Manager that is already being exploited for remote code execution without authentication.
impact: An attacker who can reach the OAuth virtual server can run code on the BIG-IP itself, the box that terminates sessions and issues access tokens for the applications behind it, and management-plane hardening plus Appliance mode do not block it.
fix: Install the engineering hotfix for your branch (Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, or Hotfix-BIGIP-17.1.3.5.0.41.14-ENG), or open an F5 support ticket for the iRule mitigation if you cannot patch today.
who: Any organization running BIG-IP APM 21.1.0, 17.5.0 to 17.5.1, or 17.1.0 to 17.1.3 where an access policy and an OAuth authorization server profile sit on the same virtual server.

Attackers are running code on F5 BIG-IP systems with no credentials at all. F5 disclosed CVE-2026-94127 on September 22, a heap-based buffer overflow in Access Policy Manager rated 9.8 out of 10 on CVSS v3.1 and 9.3 on CVSS v4.0. Exploitation was already happening when the advisory went out. CISA added the flaw to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until September 25, three days, to apply mitigations.

The blast radius is the worst part. APM is the module that decides who reaches your applications and networks. On an affected system it is also issuing OAuth access tokens. Code execution on that device means code execution on the thing that terminates sessions, holds the certificates and mints the tokens for everything behind it.

The exact condition that makes you vulnerable

This is not every BIG-IP, and it is not every APM deployment. The vulnerable configuration is narrow and specific: an APM access policy and an OAuth authorization server profile on the same virtual server, with APM acting as the OAuth authorization server. In F5's configuration guide for APM 17.1, 17.5 and 21.0, that profile is built under Access, then Federation, then OAuth Authorization Server, then OAuth Profile, and selected in an access profile attached to the virtual server.

Systems where APM is only an OAuth client or a resource server, with no authorization server profiles configured, are not affected. That distinction is the difference between an emergency change window and a routine patch cycle, so confirm it on the box rather than from an inventory spreadsheet.

⚠️ Management-plane hardening does not save you — The malicious traffic goes to the data-plane virtual server, not to the management interface. Restricting access to the management IP, which is the standard advice for most BIG-IP advisories, provides no protection here. F5 also confirms that systems running in Appliance mode are vulnerable. If the virtual server is reachable, and for an OAuth authorization server it usually is reachable from the internet by design, you are exposed.

Affected versions and hotfixes

Branch 21.1: version 21.1.0 before the hotfix. Fixed in Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.
Branch 17.5: versions 17.5.0 to 17.5.1 before the hotfix. Fixed in Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.
Branch 17.1: versions 17.1.0 to 17.1.3 before the hotfix. Fixed in Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
End of Technical Support versions: F5 did not evaluate them. Treat unknown as vulnerable, not as safe.

There is a trap in that table for anyone who patched earlier this year. CVE-2025-53521, another APM flaw, landed in CISA's KEV catalog in March. Its fixes were 17.1.3 and 17.5.1.3. Both of those builds fall inside the affected ranges above. A system you already patched in March against the previous APM zero-day still needs this new hotfix if APM acts as an OAuth authorization server on it. Do not let the earlier remediation ticket close this one.

The advisory changed after publication

F5 updated its CVE record at 00:45 UTC on September 23 to narrow the condition to the authorization server role specifically. CISA's KEV entry and the CERT-EU advisory were both published before that change and describe the trigger more broadly, as an access policy plus an OAuth profile on a virtual server. If your team scoped the exposure from the KEV entry or from CERT-EU in the first hours, you may have pulled in client-only and resource-server deployments that are not actually affected. Rescope against the current F5 record before you burn a change window on systems that do not need it.

Hunting for compromise

F5 published indicators, relayed through CERT-EU. No single one of these is conclusive. The combination that should trigger a human looking at the system is repeated OAuth authentication failures, then suspicious commands, then a TMM abort shortly after.

APM log: repeated failed UserInfo requests in /var/log/apm carrying the error description "The access token is invalid." Ten or more from a single source IP in a short window is the threshold F5 calls out.
OAuth counters: an unexplained climb in total_failed relative to total_requests and total_userinfo_requests.
Audit log: unexpected commands in /var/log/audit timestamped around those failures.
TMM core files: F5 has observed TMM entering a loop, after which the SOD daemon sends a SIGABRT. Not proof on its own, worth investigating when it lines up with the above.

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed
grep -c "The access token is invalid" /var/log/apm
ls -la /var/core/ 2>/dev/null | grep -i tmm

Order of operations matters

CISA: iRule first, then the hotfix — CISA told agencies to apply the iRule mitigation first "to allow for proactive forensic triage," then "install the final vendor patch as soon as possible." CERT-EU sequences it the same way: preserve forensic evidence, apply the hotfix, check for signs of compromise, start incident response if you find any. The iRule is not published publicly. Customers obtain it by opening a ticket with F5 support, so open that ticket now even if you plan to patch tonight.

What the advisories do not tell you

Three gaps are worth stating plainly, because your incident response plan has to account for them. F5's CVE record and the CISA and CERT-EU advisories do not say how many systems were attacked, who the attackers are, or which organizations were targeted. They also do not say whether installing the hotfix removes access an attacker already established. Treat the hotfix as closing the door, not as evicting anyone already inside.

For a device this central, that means the patch is step one of three. Patch, hunt using the indicators above, and then rotate what the box holds: OAuth signing keys, client secrets, device certificates and any administrative credentials stored on or reachable from the BIG-IP. If you find indicators, assume the tokens that device issued during the exposure window are untrustworthy and invalidate sessions downstream.

Priority order for the next 24 hours

Enumerate every BIG-IP running 21.1.0, 17.5.0 to 17.5.1, or 17.1.0 to 17.1.3, including the ones you patched in March for CVE-2025-53521.
On each, confirm whether any virtual server carries both an access policy and an OAuth authorization server profile. That is your real target list.
Open the F5 support ticket for the iRule mitigation for anything you cannot patch inside the change window.
Pull /var/log/apm, /var/log/audit and the tmctl OAuth counters off the affected boxes before you change anything, so you keep the forensic record.
Install the branch hotfix, then rotate keys and secrets on any system where the indicators line up.

Originally published on RedEye Threat Intelligence.

Check Point Management Server Zero-Day: 61 Days From Exploit to Fix

Etairos.ai — Tue, 22 Sep 2026 20:06:11 +0000

TL;DR

what: Check Point patched CVE-2026-93616 on September 22, a path traversal in the Security Management Server web service that attackers used for unauthenticated script execution in targeted attacks on July 23.
impact: The management server holds firewall policy for every gateway it manages, so code execution there is control of the ruleset, not a single host compromise.
fix: Install the fixed Jumbo Hotfix take listed in Check Point support article sk1000171, and note that LivePatch Take 28 or 29 from September 16 does not remediate this CVE.
who: Anyone running Security Management on R82.20, R82.10 Take 44 or below, R82 Take 126 or below, R81.20 Take 166 or below, or any end of support release, plus Spark and Security Gateway owners exposed to CVE-2026-85102.

Check Point patched a zero-day in its Security Management Server on September 22, 61 days after attackers used it. The company says a handful of targeted attacks on July 23 exploited CVE-2026-93616, a path traversal bug in the management server web service that lets an unauthenticated attacker upload and run scripts. Check Point rated it 9.8 out of 10 on CVSS. The management server is the box that holds firewall policy for every gateway it manages, so code execution there is not a single host compromise, it is control of the ruleset.

A path traversal that ends in script execution

The web service on the management server does not properly restrict which files and folders a request can reach. An attacker who can reach that service writes a script to a location the server will run, then triggers it. No credentials, no session, no prior foothold beyond network access to the web service.

Check Point's advisory does not say what network position an attacker needs, and that gap matters. A management server reachable only from an internal admin VLAN is a very different risk than one answering on a public address. The advisory also does not name the July targets, does not attribute the activity, and does not describe what the attackers did after exploitation. Hunting guidance and indicators of compromise are in support article sk1000171. Installing the fix tells you nothing about whether you were hit before it, so treat patching and hunting as two separate tasks with two separate owners.

⚠️ LivePatch Take 28 does not cover this — On September 16 Check Point fixed a different management server flaw, CVE-2026-91843, through LivePatch Take 28, or Take 29 on R82.20. Check Point says those takes do not remediate CVE-2026-93616. If your change record reads "LivePatch applied September 16" and the ticket is closed, the server is still exposed.

The version math catches people who already patched

Check Point numbers Jumbo Hotfix updates for each release by Take, and the LivePatch channel uses a separate take sequence. The CVE record lists these management server versions as affected:

R82.20 with no Jumbo Hotfix installed
R82.10 with Jumbo Hotfix Take 44 or below
R82 with Jumbo Hotfix Take 126 or below
R81.20 with Jumbo Hotfix Take 166 or below
R81.10 with Jumbo Hotfix Take 190 or below (end of support)
R81, R80.40, R80.30, R80.20, R80.10 and R80, all end of support

Here is the trap. CVE-2026-85103, a VPN certificate flaw Check Point fixed on September 9, affected management servers as well as gateways. On R82.10, R82 and R81.20 the affected range for CVE-2026-93616 runs one take higher than the range for that September flaw. A server patched just far enough to clear the September 9 issue is still vulnerable to the September 22 one. Note also the disagreement in the source material: the CVE record qualifies R82.20 as affected only with no Jumbo Hotfix installed, while Check Point's own advisory lists R82.20 with no condition. Assume the broader reading until Check Point clarifies.

Second front: Spark firewalls under active probing

Since September 12, attackers have been trying to exploit CVE-2026-85102, a flaw in how Check Point gateways validate certificates while a VPN connection is being established. It may let an unauthenticated attacker run code on the gateway. Check Point shipped the fix on September 9 with no evidence of exploitation at the time. Three days later the attempts began, concentrated on Spark, the small business firewall line. That is the familiar sequence: the patch is the disclosure, and the window between release and weaponization is now measured in days.

Affected products are Security Gateway and Spark, centrally or locally managed, on R81 and R81.10 (both end of support), R81.10.x, R81.20, R82, R82.00.x and R82.10. The Netherlands NCSC notes the flaw applies when these products use Site-to-Site VPN or Remote Access VPN. Check Point says the attempts arrived from anonymizing infrastructure including commercial VPN services and proxies, using certificates with these subjects:

CN=vpn,OU=users,O=global
CN=vpn-user,OU=users,O=global
CN=vpnuser,OU=users,O=global

That list is explicitly incomplete. Do not build a detection that only matches those three strings. Hunt on behavior instead: any certificate based Mobile Access login you cannot tie to a known user or a known source, followed by internal port and service scanning from the gateway's client pool. Check Point says customers who installed the September 9 fix are protected, but the advisory does not say whether any attempt succeeded.

If a gateway cannot be patched this week — For Site-to-Site VPN, the NCSC lists a Check Point workaround: turn off the implied VPN rules and permit UDP 500 and 4500 only from specific peer IP addresses. The workaround does not apply to locally managed Spark firewalls, which need the fix in sk1000117. Remote Access VPN gets no equivalent workaround, so those gateways are a patch or accept the risk decision.

What to do this week

Inventory every management server and record its release plus Jumbo Hotfix take, then compare against the affected list above rather than against your last change ticket.
Install the fixed build named in sk1000171. LivePatch takes from September 16 do not substitute for it.
Run the sk1000171 hunting guidance and indicator checks on every management server, including ones you patch, because patching erases nothing and proves nothing about July.
Confirm which gateways and Spark units are on the CVE-2026-85102 affected list and whether they run Site-to-Site or Remote Access VPN, then apply sk1000117 or the NCSC workaround.
Pull Mobile Access authentication logs back to September 10 and review every certificate based login, not only the three published subjects.
Check whether any management server web service is reachable from outside your admin network. The advisory does not define the required access path, so close it by policy.

Originally published on RedEye Threat Intelligence.