> ## Content Index > Fetch the complete content index at: https://secblog.reedcloudsec.com/llms.txt > Use this file to discover other available public pages before exploring further. # SecBlog Weekly — Issue 005 - URL: https://secblog.reedcloudsec.com/secblog-weekly-issue-005/ - Published: 2026-09-29T21:31:20.000Z - Updated: 2026-09-29T21:35:30.000Z - Description: Citrix NetScaler zero-days under active exploitation, a Supabase misconfiguration exposing 16,000+ databases, an AI agent's destructive Azure attack, a malicious npm campaign, an MCP OAuth flaw, and a ShinyHunters arrest. - Author: Marselis A. Reed - Tags: News Roundup *Week of Sep 29, 2026 · secblog.reedcloudsec.com* The signal, not the noise, in security. 6 things from this week worth your five minutes. --- [**Two Citrix NetScaler Zero-Days Under Active Exploitation as CISA Sets a Federal Deadline**](https://www.bleepingcomputer.com/news/security/cisa-orders-feds-to-patch-exploited-citrix-flaws-by-wednesday/?ref=secblog.reedcloudsec.com) (CVE-2026-88771 and CVE-2026-88772, CVSS 9.5 each) Two unauthenticated remote-code-execution flaws hit NetScaler ADC and Gateway in default configurations. CVE-2026-88771 traces, per watchTowr Labs' analysis, to `ns_monuploadd_err.pl`, a Perl script that processes NetScaler's own crash data — an attacker can inject arbitrary shell commands through data that NetScaler itself writes to its logs, reached via the `/nf/auth/doAuthentication.do` endpoint, for root-level code execution. CVE-2026-88772 needs DTLS enabled, which is the default on VPN virtual servers, and gives the same outcome or a denial of service. GreyNoise clocked the earliest exploitation attempts on September 24; the Dutch NCSC privately warned organizations to shut appliances down before Citrix publicly confirmed exploitation on September 27, the same day CISA added both CVEs to its Known Exploited Vulnerabilities catalog and, under Binding Operational Directive 26-04, gave federal civilian agencies until September 30 to secure every vulnerable appliance — a three-day window, with CISA's own advisory acknowledging that patching "can be complex and may require downtime." Fixed versions are 14.1-73.37+ and 13.1-64.23+ (plus matching FIPS builds); versions 12.1 and 13.0 are end-of-life with no patch coming at all. Scan counts vary by source and date — Shadowserver counted roughly 23,000 exposed instances, Unit 42 put it above 50,000 a day later — which is a reminder that internet-exposure numbers are a snapshot, not a fixed count, and worth re-checking rather than quoting once. The root cause fits a pattern this newsletter keeps running into: unsanitized, attacker-influenced input reaching a code-execution sink, the same failure mode behind the Cisco Secure Email Gateway root RCE two issues back, with NetScaler's own crash-log pipeline standing in for the email parser this time. And because CVE-2026-88771 hands an attacker root, the same rule applies here that applied there — a device that was actually exploited needs to be treated as untrustworthy and rebuilt, not just patched, since root access lets an attacker erase the very indicators of compromise you'd use to tell whether it was hit in the first place. The other half is a point this pillar has made before about perimeter gateways specifically: they're a recurring initial-access path, so their patch cadence needs to match their exposure, not an organization's general patch schedule. Since 2021, CISA has flagged 26 actively exploited Citrix vulnerabilities, six of them abused by ransomware gangs — the perimeter keeps being the door that gets kicked in first — and for the two NetScaler versions with no patch available at all, an EOL appliance sitting at that door needs a replacement plan now, not a place on next quarter's roadmap. *via BleepingComputer, The Hacker News, and CISA · Sep 28, 2026* [**16,000+ Misconfigured Supabase Databases Expose PII, Passwords, and Auth Tokens**](https://www.bleepingcomputer.com/news/security/misconfigured-supabase-apps-expose-data-in-over-16-000-databases/?ref=secblog.reedcloudsec.com) UpGuard researchers scanned roughly 300,000 domains showing signs of Supabase usage and found more than 16,000 databases exposing data to anyone who queried them. The cause, in UpGuard's own words, is that "the humans... do not understand their database's configuration" — missing or ineffective row-level security (RLS) policies, and misuse of public API keys, not a flaw in the Supabase platform itself. Personal information turned up in over half the exposed databases, with passwords and auth tokens in a smaller subset and some credit card data in a very limited number. Specific finds included 100,000+ customer records at a U.S. valet service, 884 plaintext passwords at a Canadian immigration service, 100,000+ private messages on an Indian platform, and 25,000 government consulate records. One detail stands out: more than 60% of the newly created databases in the dataset were built with AI-assisted development tools. RLS in Postgres, and in Supabase specifically, is opt-in and enforced per table — creating a table doesn't secure it, and a working app is not evidence that its data is protected. The deeper issue is treating security as something bolted on after a database is already exposed, instead of a first-class part of schema design: RLS deserves the same up-front attention as indexing, table joins, and views, decided when the schema is designed, not audited in later. Part of why it doesn't happen is a skills gap more than negligence — dedicated database administrators are a scarce, expensive specialty that most companies below enterprise scale don't retain, so nobody owns the schema's security posture as an ongoing job. Two controls belong in routine maintenance, not one-time setup. API keys should rotate on an agreed schedule as an access control in their own right, not something set once at launch and forgotten, and any plaintext secrets found sitting on a server should be purged as standard housekeeping, not incident response. The AI-tooling correlation needs a precise framing, too: an AI-assisted tool is only as sound as the context and constraints its user actually gives it, so a schema it generates deserves the same holistic review and full-team understanding as one written by hand — and no code, AI-assisted or not, should ship without a manual security review first. *via BleepingComputer and UpGuard · Sep 28, 2026* [**JadePuffer: AI Agent Automates a Destructive Attack Chain Against an Azure Tenant**](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/?ref=secblog.reedcloudsec.com) Microsoft, which tracks the actor as Storm-3168, observed two JadePuffer attacks in June 2026 (Sysdig separately documented the tool's emergence in July, including an expansion toward AI model data and vector databases). Credentials for one Azure service principal had appeared in a public GitHub issue before the attack; Microsoft couldn't fully confirm that as the entry point, but it's the leading candidate. From there, an AI agent automated the entire chain — reconnaissance, credential theft, lateral movement, persistence, and destruction — with no apparent human operator in the loop for most of it. Using the first compromised principal, it made more than 30 requests retrieving storage account keys, most of them successful. A second principal then carried out the destructive phase, which lasted just seven minutes and hit over 100 storage accounts plus Key Vaults, Function Apps, virtual machines, and App Services; it also attempted to delete Azure SQL databases, which failed only because of an unsupported API version, and stripped backup protections from what it could reach. Azure resource locks blocked some of the deletions, but not all of them. Start with the exposure itself: a service-principal credential sitting in a public GitHub issue is a full confidentiality breach the moment it's posted, whether or not it's ever proven to be the entry point — a secret committed to a repository, public or private, is a violation of the confidentiality leg of the CIA triad, not a lesser cousin of one. That standard should be absolute, and it applies specifically to `.env` files: they should never be pushed to any repository, public or private, since "private" only changes who can see the mistake, not whether it's still a live credential sitting in plaintext. Secrets scanning needs to cover issues and comments continuously, not just code at merge time, and organizations need a standing initiative to audit every access control tied to a service principal or app registration, not a one-time cleanup triggered by an incident like this one. The response side matters just as much, given how fast this moved: more than 30 key-retrieval requests from one principal, followed by a second principal deleting over 100 storage accounts in seven minutes, is exactly the kind of burst that rate limiting on management-plane API calls should catch and slow down, buying time that alerting alone doesn't. And alerting still needs a person on the other end of it — logging nobody reviews is a control in name only, so this is a case for routine human eyes on access logs as a real mitigation, not just automated rules, to catch the pattern before the destructive phase rather than after it. Resource locks did stop part of the destruction here, but not all of it, which means they're not comprehensive by default and are worth auditing specifically for coverage rather than assumed to be blanket protection once enabled somewhere in the tenant. *via BleepingComputer, Dark Reading, and Microsoft · Sep 28, 2026* [**PhantomSub: 101 Malicious npm Packages Hijack Developers' WhatsApp Sessions**](https://thehackernews.com/2026/09/101-malicious-npm-packages-add.html?ref=secblog.reedcloudsec.com) OX Security researchers found 101 malicious npm packages, collectively downloaded roughly 490,000 times (116,000 in the last 30 days alone), with names like `ourin-baileys`, `@nexustechpro/baileys`, `levvleys`, `neuralwhatsapp`, and `my-auto-follow`. They abuse Baileys, a legitimate open-source WhatsApp library — not malicious itself — to silently subscribe a developer's already-authenticated WhatsApp bot session to attacker-controlled channels without consent. Researchers found three variants: 19 packages fetched channel IDs from GitHub at runtime, 60 embedded them in cleartext source, and 14 used obfuscated, encoded IDs. The channels being boosted were mostly Indonesian bot-seller, game-resource, and social-media-growth operations, which tells you the actual goal: engagement fraud, not data theft or ransomware. OX's write-up, dubbing the campaign PhantomSub, follows related Baileys-abuse findings from SafeDep and Xygeni Security earlier in August and September, suggesting this is a pattern, not an isolated incident. It's worth naming the mundane motive plainly rather than dressing it up — this is follower-farming, not a data-theft ring — but the mechanism underneath it is the same session-hijack technique used in far more damaging campaigns, and the fact that the payoff here is small doesn't mean the next package abusing the same trick will be. Any dependency that legitimately needs a live authenticated session — a WhatsApp, Slack, or Discord bot library, for instance — is a session-theft target regardless of how the abuse eventually shows up. The same framework this newsletter applied to the malicious Terraform providers a few issues back holds up here. Start with what the tooling already provides: npm's lockfile records an integrity hash for every installed package and verifies it on `npm ci`, so commit `package-lock.json` and review any change to it the way you would a dependency bump itself. That hash shows a package hasn't been tampered with in transit, not that the package is trustworthy, so check who actually publishes it — none of these 101 packages shipped from Baileys' own maintainers or its official scope, and an unfamiliar publisher extending a popular library's name is a signal worth noticing on its own. Then add what a lockfile can't provide: dependency scanning that flags malicious behavior, not just known CVEs, since a freshly published malicious package by definition has none to match against. And put a triage step in front of any new dependency, especially one that touches a live authenticated session, so adding it needs a reviewer's approval rather than a single line in a `package.json` diff. Software supply-chain security fails the same way whether the registry is Terraform's, Go's, or npm's — when nobody owns the question of what just entered the dependency tree. *via The Hacker News and OX Security · Sep 29, 2026* [**Official MCP Python SDK OAuth Flaw Could Have Let a Malicious Server Steal Credentials**](https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html?ref=secblog.reedcloudsec.com) This is a disclosed-and-fixed design flaw, reported by Cycode, not an active attack — worth saying plainly up front. The official Model Context Protocol Python SDK, versions 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1, didn't always validate that the authorization-server endpoint an MCP server pointed a client toward was legitimate. A malicious or compromised MCP server could exploit that gap to redirect an OAuth flow and capture client secrets, authorization codes, and PKCE proof keys, then use them to request a valid access token from the real login service with whatever permissions the client application held. The affected provider classes were `OAuthClientProvider`, `ClientCredentialsOAuthProvider`, and `PrivateKeyJWTOAuthProvider`. Fixes shipped September 7 (1.30.0 and 2.2.0), with the public security advisory following three weeks later, on September 28\. No CVE has been assigned, and neither Cycode nor the advisory reports any evidence this was exploited before the fix. MCP's whole value proposition is letting an AI agent talk to third-party servers on the user's behalf, which makes an OAuth validation gap here a step worse than an ordinary web OAuth bug: a compromised or malicious MCP server isn't a site a person happened to visit, it's a tool the agent was explicitly configured to trust. Update past 1.30.0 or 2.2.0 now, even with no known exploitation — a fixed vulnerability in a component this new and this fast-moving is exactly the kind of thing that gets rediscovered by someone less well-intentioned than Cycode. More generally, "the server told my client where to authenticate" is an assertion to verify, not a default to follow, which is the same rule that governs any redirect-based auth flow, agentic or not. The same principle belongs one level up, on the workflow itself and not just the credential handling: an AI agent or MCP-connected workflow shouldn't be allowed to free-flow from request to action unsupervised, especially anything touching authentication, a permission grant, or a destructive operation. That means a real notification step — a human actually sees what the agent is asking for or about to do, which server, what scope, what action — and gives explicit approval before it proceeds, rather than the agent completing the handshake and moving on unattended. A gate like that wouldn't have stopped this particular SDK flaw from existing, but it's the general control that limits what any agentic workflow can do unsupervised, credential bug or not — including this issue's own JadePuffer item, where nothing stood between the agent and the deletion it carried out in seven minutes flat. *via The Hacker News and Cycode · Sep 29, 2026* [**ShinyHunters: A Dutch Arrest, and a Renewed Oracle PeopleSoft Campaign With a WAF Bypass**](https://www.securityweek.com/google-warns-of-shinyhunters-fresh-oracle-peoplesoft-campaign/?ref=secblog.reedcloudsec.com) (CVE-2026-35273) Mandiant and Google, tracking the group as UNC6240, reported a renewed Oracle PeopleSoft exploitation campaign on September 28 that bypasses web application firewalls protecting the same CVE-2026-35273 exploited in a mass-exploitation wave against 100+ customers back in June. The bypass is simple: in request paths containing `/PSEMHUB`, replace the letter "P" with its URL-encoded form, `%50`. As Google explains it, "many WAF and reverse proxy rules match the literal path before URL decoding, while the PeopleSoft application server decodes the request and routes it to the vulnerable servlet" — so the encoded path sails past the firewall and still reaches the flaw underneath. Once in, the group deployed JSP web shells for persistence, the SideEye backdoor for credential theft and system management, the Neo-reGeorg tunneling toolkit for lateral movement, and MeshCentral for remote management, alongside abuse of PeopleSoft and WebLogic service accounts to reach databases directly. The original wave targeted education; this renewed one has expanded into agriculture, government, healthcare, IT services, technology, and transportation. Separately, Dutch police confirmed the September 15 arrest of Pepijn van der Stap, 24, of Amsterdam — previously convicted in 2023, under the alias "Umbreon," of hacking and extorting over a dozen companies, and now under investigation for ties to ShinyHunters, based partly on that same Umbreon alias and Pokémon imagery reappearing in the group's recent FBI and Cl0p leak-site breaches. The attribution isn't clean, though: the same Umbreon character shows up in a 2020 HackForums defacement that predates van der Stap's account, and sources close to him told DataBreaches that a police-released voice recording tied to the Odido hack "did not sound like him." ShinyHunters itself denies any connection to him. He appeared before a Rotterdam court on September 29, and the case is ongoing. The WAF-bypass half is the actionable one: Oracle's patch for CVE-2026-35273 has existed since the original disclosure, so the real gap is treating a WAF signature as equivalent to the patch it was only ever meant to supplement. A control at a different layer than the one doing the decoding is exactly the mismatch this bypass exploited, and tightening the WAF rule further just invites the next encoding variant — apply the actual patch instead. The arrest earns its place as the human follow-up to a story we've now covered across two issues, but the framing has to hold the uncertainty rather than resolve it for readers — even the researchers who drew the Umbreon connection flag a real discrepancy in the evidence. *via SecurityWeek, BleepingComputer, and Google/Mandiant · Sep 28–29, 2026* --- *That's Issue 005\. Free weekly, no spam, unsubscribe anytime — secblog.reedcloudsec.com*