> ## 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 006
- URL: https://secblog.reedcloudsec.com/secblog-weekly-issue-006/
- Published: 2026-10-07T19:42:06.000Z
- Updated: 2026-10-07T19:42:06.000Z
- Description: An FBI contractor's missed patch, 8.8 million Danish records exposed through a company account, Arizona's court breach, Atlassian and FortiBleed attacks, Warlock's SharePoint campaign, SWIFT middleware, and a LibreOffice flaw.
- Author: Marselis A. Reed
- Tags: News Roundup

*Week of Oct 6, 2026 · secblog.reedcloudsec.com*

The signal, not the noise, in security. 8 things from this week worth your five minutes.

---

[**FBI Blames Contractor's Missed Patch for ShinyHunters Breach**](https://www.securityweek.com/fbi-blames-contractors-missed-patch-for-shinyhunters-breach/?ref=secblog.reedcloudsec.com)  
The FBI says a contractor's failure to apply a security patch exposed the personal information of "thousands" of bureau employees, and that it has removed the contractor. Brett Leatherman, assistant director of the FBI's cyber division, described "a security failure of a platform managed by a third-party organization" in which a contractor "failed to implement a security patch." The FBI has not named the contractor or the platform. Reuters, citing two anonymous sources, identified them as Accenture and Oracle's PeopleSoft HR platform; Accenture said only that it is "proud to support the mission of the FBI" and did not address the patching claim. The FBI's statement doesn't mention ShinyHunters, and no source confirms that it describes the same incident as the group's September 22 claim, though the PeopleSoft detail points that way. No exact victim count, patch, or CVE has been given. The Hacker News notes that Mandiant's separate assessment concerns a bypass for CVE-2026-35273, but nothing ties that flaw to the contractor's missed patch.  
The FBI's account also sits uneasily with the version of events we ran in [Issue 004](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=FBI%20Investigating%20Alleged%20ShinyHunters). ShinyHunters claimed a PeopleSoft zero-day with no CVE, which BleepingComputer couldn't verify; the FBI's account describes a flaw with a fix already available and unapplied. The two may not be the same system, and the group's own claims remain unverified, but the patch explanation is the one an official source has now put on the record.  
The lesson is about who owns the patch. Outsourcing a system's operation doesn't outsource accountability for its patch state, and a contractor-run platform holding employees' personal data deserves the same scrutiny as an internet-facing system: contractual patch deadlines, evidence that fixes were applied, and independent verification rather than trust. Vigilance has to cover third parties as well as internal users, the same point as [the Astrana item in Issue 004](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Astrana%20Health%20Data%20Breach). It's also [Issue 005's PeopleSoft point](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=ShinyHunters%3A%20A%20Dutch%20Arrest) from the vendor-management side: a compensating control is not the patch, and neither is a contract clause promising one. Then assume a patch gets missed anyway. HR records for current and former employees should be archived out of the platform's reach and encrypted, with PKI controlling who holds the keys, so a missed patch doesn't become a readable data set. That is the at-rest and in-flight argument from [Encryption at Rest and in Transit](https://secblog.reedcloudsec.com/encryption-at-rest-and-in-transit-the-actual-case-and-what-it-costs-you/), applied to a contractor-run system.  
*via SecurityWeek and The Hacker News · Oct 6, 2026*

[**Denmark Says Attackers Accessed CPR Data for 8.8 Million People via Company Account**](https://thehackernews.com/2026/10/denmark-says-attackers-accessed-cpr.html?ref=secblog.reedcloudsec.com)  
Attackers used a private Danish company's lawful right to look up records in the Central Person Register (CPR) to pull the names, addresses, and personal identification numbers of about 8.8 million people, living and dead, according to Denmark's digitalization ministry. That is roughly four in five of the roughly 11 million people the register has recorded since 1968, and the ministry says the figure isn't final. The ministry says the access didn't cover people with name-and-address protection, though it hasn't said whether their CPR numbers were reached. The access began in early September and ran for about ten days before a register employee noticed unusual activity on October 2; the ministry announced the breach on October 5\. Denmark's data protection authority describes a very large number of automated lookups used to identify valid CPR numbers, though it hasn't yet assessed the case, and BleepingComputer reports that detail with a hedge. The company isn't named, how it was compromised hasn't been explained, and there is no attribution or extortion claim. Police are investigating, the company's access has been blocked, and Minister Christina Egelund has requested a full security review, saying the safeguards weren't solid enough and that alarms should have gone off given how long the access lasted.  
This wasn't a break-in so much as a legitimate access path used at a volume nobody was positioned to question, and the minister's own comment is the argument for the controls laid out in [Issue 005's JadePuffer item](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=JadePuffer%3A%20AI%20Agent%20Automates). Audit every access control, including the ones granted to partners, against what each one actually needs rather than what it was originally given. Put rate limiting on lookups, so enumerating valid IDs across millions of records is slow and loud instead of quick and quiet. And put human eyes on the logs, on a short cadence. [Issue 004's OpenAI item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=OpenAI%20Agent%20Breached%20Australian) argued that a routine look at what was read, modified, or accessed, daily for sensitive systems, surfaces misuse in days rather than weeks. Ten days of automated lookups is what that review exists to catch, and a run of lookups for numbers that don't exist followed by hits on ones that do is the enumeration pattern worth alerting on. Where a partner's legitimate need is a lookup, scope it narrowly, and require an approval step for bulk access, as you would for any store of PII.  
The public guidance carries the second lesson: a CPR number should not be the only proof of identity. Once an identifier is exposed at this scale, it can't work as an authenticator, which is the same point as caller ID and a trusted sender domain in the [Astrana](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Astrana%20Health%20Data%20Breach) and [Revolut](https://secblog.reedcloudsec.com/secblog-weekly-issue-003/#:~:text=Revolut%20Handed%20Customer%20Data) cases. Any process that treats knowing a person's ID number as proof of who they are needs a second factor that doesn't depend on it.  
*via The Hacker News, BleepingComputer, and The Record · Oct 5, 2026*

[**Personal Information for Over 1 Million People Stolen in a Cyberattack on Arizona's Court System**](https://www.securityweek.com/personal-information-for-over-1-million-people-stolen-in-a-cyberattack-on-arizonas-court-system/?ref=secblog.reedcloudsec.com)  
The Arizona Supreme Court says attackers copied personal information on about 1.3 million people from the state's court systems. The data covers records of people with unpaid court fees, fines, and restitution from traffic and criminal violations, going back as far as 30 years, along with nearly 30,000 active and inactive orders of protection and 150,000 reports dating back to 2010 from a foster care board. The court says information on jurors, witnesses, and court employees wasn't taken, nothing was altered or deleted, and no cases were delayed. The breach is believed to have started when a court employee clicked a malicious link in an email, though that isn't confirmed as the sole cause. Court technology staff shut down the attack on a backup server about two hours after spotting it on September 24\. The court says there is no evidence the data has been misused, a spokesperson said it was not ransomware, and no group has claimed it; Chief Justice Ann Scott Timmer's reference to "criminal hackers or their bots" is as close as the court has come to saying who.  
The entry point, if the court's belief holds, is the oldest one in the book, and it's [the Astrana pair from Issue 004](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Astrana%20Health%20Data%20Breach) again: quarterly security-compliance training for internal staff and third parties alike lowers how often the trick works, and access controls limit what a successful one can reach. The second half is the one on trial here. Three decades of fee records, orders of protection, and child-welfare reports ended up in attackers' hands after, apparently, a single click. Records that sensitive should require encryption, an approval request, or both to reach, and legacy records belong in encrypted archives, out of reach of day-to-day accounts, with PKI controlling who holds the keys, as in the FBI item above.  
*via SecurityWeek and The Record · Oct 6, 2026*

[**Critical Atlassian Flaw Lets Unauthenticated Attackers Read Known Files Across 8 Products**](https://thehackernews.com/2026/10/critical-atlassian-flaw-lets.html?ref=secblog.reedcloudsec.com) (CVE-2026-21589, CVSS v4.0 score 9.3)  
Atlassian disclosed an unauthenticated arbitrary file-read flaw on October 5 that affects eight self-hosted products: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, and Crowd (all Data Center), plus Crucible and Fisheye. An attacker who knows a file's exact name and path can read files in a product's web application root, but can't list directories. watchTowr traced the root cause to a shared web-resource library that converts "::" into "/", which lets a request use plugin resource endpoints to traverse paths, though not out of the Tomcat application context. The practical risk is credentials: in a Jira instance integrated with Crowd, an attacker can read plaintext credentials from `crowd.properties` and use Crowd's API to create a Jira administrator account, provided Crowd is reachable and the application has sufficient permissions. Fixes include Jira Software DC 9.12.40, 10.3.26, and 11.3.12; Confluence DC 9.2.26 and 10.2.19; Bitbucket DC 9.4.26, 10.2.8, and 10.5.1; and Crucible and Fisheye 4.9.15\. Check Atlassian's bulletin for Bamboo, Jira Service Management, and Crowd, where the published version details are inconsistent in places. Atlassian's cloud products are patched and need no action.  
watchTowr published a technical write-up and public proof of concept after the advisory, and Previdian's honeypots recorded exploitation attempts about two hours later: 15 attempts from three IP addresses in Japan and the United States, with no confirmed successful compromise. A Nuclei template for mass scanning has since been released. Atlassian says it found no evidence of exploitation in its own cloud products but can't confirm whether self-hosted instances were affected, and its log-hunting guidance, which involves URL-decoding request lines and searching for traversal patterns, doesn't explain how to tell a failed attempt from a successful read.  
As with [the WordPress flaw in Issue 004](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Attackers%20Exploit%20WordPress%20CVE), the window between public details and exploit attempts was hours, not sprints, so the same emergency-change rule applies. Until the fix is applied, the vendor's WAF rule, which blocks `..` next to a slash, backslash, or `::` (URL-encoded forms included), is a stopgap, worth tuning in audit mode before moving to prevention, but not a substitute for the patch. Better still, ask why these systems are reachable from the internet at all. A source-IP allowlist, the control from [Issue 004's Check Point item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Check%20Point%20Warns%20of%20Hackers), turns an internet-wide problem into a known-network one, and BleepingComputer's account of watchTowr's research notes an allowlist would make the Crowd attack much harder. Then fix the part that made a file read dangerous. Bitbucket and Bamboo sit in the middle of source code and build pipelines, so, as with [the TeamCity breach at JetBrains in Issue 002](https://secblog.reedcloudsec.com/secblog-weekly-issue-002/#:~:text=Attackers%20breached%20JetBrains%20Cadence), a flaw on one is access to every credential it was ever trusted with, and here those credentials sit in plaintext in a readable configuration file. Secrets stored in plaintext should be purged from servers as routine maintenance and rotated on an agreed schedule, as [Issue 005 argued about Supabase](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Misconfigured%20Supabase%20Databases). Since Atlassian can't tell you whether you were read, assume any credential in a readable file may have been, and rotate it.  
*via The Hacker News and BleepingComputer · Oct 7, 2026*

[**FBI Warns FortiBleed Remains Active After Amassing 86,644 Fortinet Device Credentials**](https://thehackernews.com/2026/10/fbi-warns-fortibleed-remains-active.html?ref=secblog.reedcloudsec.com)  
The FBI and Secret Service warned on Tuesday, October 6 that FortiBleed, a credential-harvesting campaign against internet-facing FortiGate firewalls and SSL VPN gateways, is still active. It isn't a software flaw and has no CVE: the agencies say it exploits "reused or leaked credentials and legacy SHA-256 password storage." Outlets disagree on the headline number. The Hacker News reports an estimated 86,644 working device credentials across 194 countries as of June 19, while The Record reports the agencies saying more than 86,000 firewalls and gateways were compromised, and credentials and devices are not the same count. The chain starts with credential stuffing and password spraying against exposed portals, using leak dumps and infostealer logs. The Hacker News describes a Go-based tool, FortigateSniffer, that passively intercepts authentication traffic across 24 protocols; harvested hashes are cracked on GPU clusters, and the operators then move into Active Directory and exfiltrate from network shares. For persistence, they create new administrator accounts on the firewall and sometimes delete or change the originals, locking owners out.  
Attribution is suspected, not confirmed: the operation is described as a Russian-speaking initial access broker, with operator overlaps pointing to INC and Lynx ransomware (The Record adds Payload), so the access is likely resold for ransomware. SOCRadar counts at least 12 organizations breached and encrypted, and reporting alleges Russian actors used the campaign to reach UK government officials' email. It became public after its operators exposed their own backend server. CISA first warned about FortiBleed in June, so this is a campaign roughly three months old and still working.  
[Issue 004's Check Point item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Check%20Point%20Warns%20of%20Hackers) made a point that fits exactly: step-up authentication can't stop a pre-authentication flaw, but it does limit what stolen credentials can do. FortiBleed is the case where stolen credentials are the entire attack. So layer the controls that make a stolen password insufficient: phishing-resistant MFA, as CISA advised in June; geo-IP restrictions, so the gateway stops answering regions where you have no users; and a second factor required outside normal working hours. Take administration off the internet entirely, or restrict it to explicit source IPs, as the agencies advise. Reset credentials on a schedule, and store them with a slow password hash such as PBKDF2, the guidance CISA gave in June, because a fast hash like SHA-256 is the wrong tool for passwords and is exactly what GPU cracking exploits. Watch for this campaign's signature: a new administrator account on a firewall is a high-signal event, worth reviewing on the same short cadence as the Denmark item, not at the next quarterly audit. The agencies also warn to expect lockouts that need remediation beyond patching and password resets. And as with [the Cisco gateway in Issue 003](https://secblog.reedcloudsec.com/secblog-weekly-issue-003/#:~:text=Root%20RCE%20Zero%2DDay%20in%20Cisco) and [NetScaler in Issue 005](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Two%20Citrix%20NetScaler%20Zero%2DDays), a firewall where an attacker held administrator rights should be treated as untrustworthy until it's rebuilt, since new admin accounts and stolen sessions are what outlast a password change.  
*via The Hacker News and The Record · Oct 7, 2026*

[**Warlock Exploits SharePoint Flaws to Disable Security Tools and Deploy Ransomware**](https://thehackernews.com/2026/10/warlock-exploits-sharepoint-flaws-to.html?ref=secblog.reedcloudsec.com) (ToolShell: CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771 · K7RKScan driver: CVE-2025-1055)  
Symantec and Carbon Black researchers describe a Warlock ransomware campaign that has hit at least four organizations: a water utility, a telecom provider, a regional government body, and a university, apparently in Portuguese- and Spanish-speaking countries across Europe, Africa, and Latin America. Symantec tracks the operators as Longlegs, also known as Storm-2603; outlets word the attribution differently, from "suspected China-linked" (The Hacker News) to "China-based" (SecurityWeek). Initial access is on-premises SharePoint through the ToolShell flaws (the four CVEs above, per BleepingComputer), exploited since mid-2025 and still working against unpatched or unmitigated servers. The attackers drop a web shell, steal ASP.NET machine keys, and use them to forge signed payloads that run code in the SharePoint application pool.  
Defenses were the next target. In one intrusion that began July 22, a tool disabled security software on at least 40 hosts within about two hours, in some cases through a bring-your-own-vulnerable-driver technique using a signed K7RKScan driver, a detail The Hacker News and BleepingComputer report and SecurityWeek doesn't name. Warlock then ran on at least 33 hosts, with the final stage on July 31 and ransomware appearing almost as soon as protection came down on each machine. The payload was staged in the domain's SYSVOL share, which replicates to every domain controller, and the operators kept remote access through Visual Studio Code's tunnel feature, installed as a service. The researchers published indicators of compromise; no ransom amounts or victim names were disclosed.  
Three threads from earlier issues apply. Patch cadence first: flaws first exploited in 2025 are still the way in, so exposed SharePoint belongs in the same bucket as [the perimeter gateways from Issue 004](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Check%20Point%20Warns%20of%20Hackers) whose patch cadence should match their exposure. Patching also doesn't undo theft. Machine keys stolen before a fix still forge valid payloads afterward, so the logic of API key rotation from [Issue 005's Supabase item](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Misconfigured%20Supabase%20Databases) applies, and keys should be rotated as part of the response rather than left to a schedule. Second, endpoint protection is itself a target. Defense in depth, as in [Issue 004's WordPress item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Attackers%20Exploit%20WordPress%20CVE), means no single control, including the EDR agent, has to be perfect: block known vulnerable drivers, protect security tools against tampering, and treat 40 agents going quiet in two hours as an alert in its own right. Third, as [Issue 002's F5 rootkit item](https://secblog.reedcloudsec.com/secblog-weekly-issue-002/#:~:text=Hackers%20breach%20F5%20BIG%2DIP%20APM) argued, once an attacker controls a host, anything measured from inside it is unreliable, so ship telemetry off the host and alert on runtime behavior, such as a web server process spawning a shell or a new service running the VS Code tunnel.  
*via The Hacker News, BleepingComputer, and SecurityWeek · Oct 2–3, 2026*

[**SWIFT Banking & Government Middleware Enables RCE**](https://www.darkreading.com/cybersecurity-operations/swift-banking-govt-middleware-rce?ref=secblog.reedcloudsec.com) (CVE-2026-18397, CVSS v4.0 score 9.4)  
Bay Area Labs found a critical flaw in SConnect, a Thales browser extension and native host used for hardware-token authentication, with more than a million users on the Chrome Web Store. SConnect handles logins to national government systems such as Qatar's Tawtheeq identity provider and the Swedish Tax Agency, to banking and insurance portals, and, for years, to the SWIFT interbank network through its 3SKey USB tokens. The extension accepted messages from any web page or embedded iframe, and its check that a site was authorized relied on a signature verification the developers built themselves. Given an oversized, invalid RSA signature, the calculation failed without writing its result, but SConnect never checked for that and read a stale buffer; a heap spray of crafted bytes could make it accept a forged result. The researchers say visiting a page with a malicious iframe is enough to load a malicious DLL and run code, end to end in six to ten seconds, and that failed attempts showed users no error.  
Thales patched the Chrome Web Store and Apple App Store versions in August, removed SConnect from Microsoft Edge in September, and published CVE-2026-18397 on October 1; it hasn't responded to Dark Reading's request for comment. SConnect also reached end-of-life last month, with SWIFT having introduced a replacement, Web Connect, in September 2025, but the researcher suspects many SWIFT users still have SConnect as a fallback, and the real blast radius is unknowable because banks keep their security practices private. Two caveats. This is a single-source exclusive: the CVE record corroborates the flaw, not the SWIFT-specific details. And the worse scenarios, relaying challenges to sign documents, stealing sessions, or moving money, are the researcher's speculation; Bay Area Labs couldn't obtain a 3SKey to test against SWIFT itself. No exploitation in the wild is reported.  
Hardware tokens are only as strong as the middleware that talks to them, and here the weak point was a security check the vendor wrote itself instead of taking from a vetted library. That is the library-integrity lesson from the [Terraform](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Attackers%20Use%20Malicious%20Terraform%20Providers) and [npm](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=PhantomSub%3A%20101%20Malicious%20npm) items in a different form, and the same framework carries over. Put a triage step in front of anything new on a privileged machine, so a browser extension or native helper needs a reviewer's approval rather than a quiet install, and require a manual security review before security-critical code ships, as [Issue 005's Supabase item](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Misconfigured%20Supabase%20Databases) argued. Then inventory where SConnect still lives, migrate to Web Connect, and retire end-of-life middleware, the same logic as [the NetScaler versions that will never get a patch](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Two%20Citrix%20NetScaler%20Zero%2DDays).  
Next, assume the middleware fails, and contain what it can reach. This attack needs only a visit to a malicious page, so workstations that hold privileged tokens should be dedicated machines that don't browse the open web, with an egress allowlist limiting them to the sites they need, the control [Issue 004's OpenAI item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=OpenAI%20Agent%20Breached%20Australian) recommended for agents. Audit every account that holds a token, since 3SKey tokens go to an organization's most highly permissioned staff, and review their activity on a short cadence, the controls from [Issue 005's JadePuffer item](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=JadePuffer%3A%20AI%20Agent%20Automates). And don't let one compromised session move money by itself: require an approval step from a second person for high-value actions, plus a second factor for anything outside normal working hours, the off-hours rule from [Issue 004's Check Point item](https://secblog.reedcloudsec.com/secblog-weekly-issue-004/#:~:text=Check%20Point%20Warns%20of%20Hackers) and the same human-approval gate [Issue 005 argued](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Official%20MCP%20Python%20SDK%20OAuth%20Flaw) for agentic workflows. Finally, note the speed: the researcher says an exploit that once needed nation-state effort came together with AI agents decompiling the native host and probing memory, even though the heap spray worked only about 18% of the time, one more sign that the time between disclosure and a working exploit is shrinking.  
*via Dark Reading · Oct 2, 2026*

[**LibreOffice and OpenOffice Flaws Let Malicious Spreadsheets Run Code Without Macro Warnings**](https://thehackernews.com/2026/10/libreoffice-and-openoffice-flaws-let.html?ref=secblog.reedcloudsec.com) (LibreOffice: CVE-2026-63277 · Apache OpenOffice: CVE-2026-59265)  
This is disclosed research with a public proof of concept, not an attack in the wild, and the two products are in different states: LibreOffice is fixed, Apache OpenOffice isn't. A malicious Calc spreadsheet can run an attacker's code the moment it opens, with none of the warning either program shows before running a macro, but only when Java support is enabled. No single feature is broken. A spreadsheet can contain a database range that refreshes automatically from an ODB database file referenced by a web address; the ODB names a JDBC driver and where its code lives, such as a JAR on a remote server; the program downloads the JAR and starts the driver, which runs the attacker's code. Each piece works as designed, and chained they reach code execution without asking the user to trust the document. LibreOffice fixed it in releases on October 5 (26.2.5 and 26.8.0). OpenOffice is unpatched through 4.1.16, with a fix expected in 4.1.17, which is still in testing. V12 published a proof of concept for both on GitHub that opens the Calculator app as a harmless stand-in; the researchers tested on Windows and Linux, and no use in the wild has been reported. The flaw was reported independently by V12 and Codean Labs.  
The mitigation is attack-surface reduction: if you don't need Java in your office suite, turn it off, which is the only protection available for OpenOffice today. Don't open spreadsheets from untrusted sources, and make that a standing training point for staff and third parties alike, not a one-time memo. A workaround isn't the same as a fix, so apply the LibreOffice update now and track OpenOffice 4.1.17\. The way this one is built is worth noticing too: convenient features chained together with no step that asks for trust. Anything that fetches and runs remote code on open deserves the human-approval gate we argued for around AI agents and [MCP workflows in Issue 005](https://secblog.reedcloudsec.com/secblog-weekly-issue-005/#:~:text=Official%20MCP%20Python%20SDK%20OAuth%20Flaw): show the user what is about to run, and require explicit approval before it does.  
*via The Hacker News · Oct 6, 2026*

---

*That's Issue 006\. Free weekly, no spam, unsubscribe anytime — secblog.reedcloudsec.com*