
The Hacker Diaries · Case File No. 046
The Hacker Diaries — Featuring Jennifer Hudsen: Case File No. 046
Eleven files landed under the lamp tonight: exploited network edges, a phone call that should wait, secrets aging in public code, a low-scored logging hole, and benchmark claims that need a cooler head than their headline. This is a defensive field brief—what is verified, what is still fog, and what a local team can do without turning fear into theater.
Reporting cutoff: October 29, 2026, 7:35 p.m. EDT (23:35 UTC). Fast-moving vendor status must be rechecked before publication or action.
Tonight’s risk at a glance
| Priority | Files | Why |
|---|---|---|
| Patch / isolate tonight | Cisco ASA/FTD, Alpine GitLab, Cisco SD-WAN, exposed PAN-OS management | Active exploitation, attempted exploitation, or verified root/control-plane consequence. |
| Verify versions tonight | Telegram Android, Linux kernels, VMware ESX | Fixed releases exist, but build, runtime and exposure details decide risk. |
| Contain human and supply-chain paths | Fake AI apps, exposed Gitee keys, npm installs | User trust, credentials and package routing are the control points. |
| Watch, do not over-promise | Gemini 4 Carbon | Vendor-reported benchmark capability is not a generally available operating control. |
The pattern is not “everything is critical.” It is that exposure, runtime and trust boundaries determine which alarms belong at the front of the queue. A patch label without an active-runtime check is paperwork; a low score after admin compromise can still erase the evidence; and a signed executable inside an untrusted bundle is not a signed bundle.

Do tonight
- Remove public management exposure from PAN-OS, ESXi/vCenter and any network control plane that does not need it.[38][35][33]
- Check affected Cisco, GitLab/Ruby, Telegram and VMware versions against the current vendor advisory, then verify the running build after change.[25][30][19]
- Revoke organization credentials that ever appeared in public source; deletion is not revocation.[22][21]
- Quarantine unofficial AI desktop installers and preserve evidence rather than executing samples.[8]
- Export short-retention appliance, identity, CI and network logs before rebooting systems suspected of compromise.[29][25]
Do this week
- Audit package-registry routes, CI exceptions and AI-agent dependency paths.[23][24]
- Test remote logging from hypervisors and network appliances with a harmless administrative action.[35]
- Inventory custom GitLab images by digest and active Ruby, not tag alone.[29][31]
- Ask managed network providers for fixed-build and compromise-hunt confirmation for Cisco SD-WAN control components.[33][34]
- Document clean-system credential rotation and trusted-image rebuild procedures before an incident chooses the hour.[29][33]
Dossier 01 · High priority; exploitation not established
The Linux TCP flaw with an MPTCP-shaped shadow
What happened & verified timeline
CVE-2026-98432 is an upstream Linux IPv4 TCP use-after-free published October 15 and scored 9.8/Critical by the kernel CNA.[1][2]
The upstream notice lists fixes across maintained branches, from 5.10.272 and 5.15.223 through 7.2.10 and 7.3.[2]
Anthropic says a controlled proof of concept reached remote root on a Linux server with an MPTCP listener, taking 48 minutes to leak a pointer and about five more minutes to execute a command.[3]
Exposure, wild observations & unknowns
At the reporting cutoff, Ubuntu showed work in progress for several generic kernels while Debian listed fixed packages; Red Hat assigned a different 8.1/Important score in its snapshot.[4][5][6]
The CVE was absent from CISA KEV catalog version 2026.10.29, which is not proof that exploitation never happened.[7]
The wild observation is the mismatch between a severe lab result and a fragmented vendor patch landscape. The unknown is not the existence of the bug; it is whether anyone outside the lab has turned the race into a reliable campaign.[2][4][6]
Local / SMB implications
For a small firm, the practical unit is the running vendor kernel, not an upstream version string copied into a spreadsheet. Internet-facing Linux appliances, custom gateways, storage nodes and hosted applications deserve exact package and reboot checks.[2][4][6]
Immediate actions
- Inventory running kernels and any exposed MPTCP listeners, then follow the exact distribution advisory rather than cherry-picking one upstream commit.[2][4][6]
- Install the vendor-supported fixed kernel when available, schedule the reboot, and keep the exposure reduction in place until the active kernel is verified.[2][4][6]
Detection / verification
The good: Maintained branches have upstream fixes and several distributions already published packages.[2][4][6]
The bad: Vendor status and scoring differ, and the strongest exploit result is still company-reported.[2][4][6]
Confidence: High on the vulnerability and upstream fixes; moderate on the MPTCP proof; low on real-world exploitation.[2][4][6]
Dossier 02 · High user-execution risk
Fake AI desktop apps and the signed-binary confidence trick
What happened & verified timeline
Check Point tracked fake GitHub and GitHub Pages projects impersonating unreleased or fabricated AI desktop products that delivered YobaDropper and YobaLoader.[8]
The lure paired legitimate signed OpenAI or Anthropic executables with a malicious DLL for side-loading; the signature authenticated the legitimate file, not the surrounding bundle.[8][9]
The observed final payload was XMRig, while the loader architecture could accept other executable or PowerShell payloads.[8][9]
Exposure, wild observations & unknowns
The first observed repository appeared around July 2026, and malicious releases followed near the end of August.[8]
Check Point described Russian-origin indicators and a UTC-4 operating pattern, but neither establishes a named actor.[8]
The strange part is how ordinary the trust signals look: a familiar brand, a public repository and a signed executable. Unknowns include victim count, geographic reach and whether payloads other than the miner were ever delivered.[8][9]
Local / SMB implications
Small businesses that let staff install unofficial “AI helpers” inherit a software-supply-chain problem without procurement review, application control or a clean inventory. A noisy miner may be the visible symptom rather than the complete incident.[8][9]
Immediate actions
Detection / verification
- Search software inventories, endpoint telemetry and browser/download history for the reported project and component names from the Check Point report.[8][9]
- Check for side-loaded DLL activity, unexpected persistence and miner processes, but remember that absence of XMRig does not clear the loader.[8][9]
The good: The campaign has usable repository, persistence and malware indicators, and it still requires a user to install an unverified package.[8][9]
The bad: Trusted hosting and a valid signature on one component can create false confidence.[8][9]
Confidence: High on the observed chain; low on victim count and actor attribution.[8][9]
Dossier 03 · Strategic watch
Gemini 4 Carbon: a benchmark lead, not a deployment plan
What happened & verified timeline
Google reported that Gemini 4 Carbon led its disclosed results on vulnerability-finding, exploitation and patching benchmarks.[10]
Google said the cyber evaluations were run without model guardrails, while access remained staged rather than generally available.[10]
Artificial Analysis independently listed a separate score of 59 for the high-reasoning configuration, not an independent reproduction of the three cyber benchmark claims.[11]
Exposure, wild observations & unknowns
The benchmark families cover different jobs, including vulnerability discovery, exploit-oriented evaluation and patch generation, so one score cannot stand in for the whole security lifecycle.[12][13][14]
The wild observation is that the same model is being framed for finding, exploiting and fixing flaws. The unknowns are independent repeatability, production false-positive rates, cost, general availability and how the staged controls perform under pressure.[10][15]
Local / SMB implications
For an SMB, this is a planning signal rather than a product recommendation. No one should promise faster patching, replace review staff or change incident playbooks around capability that is not generally available and whose headline cyber scores remain vendor-reported.[10][15]
Immediate actions
Detection / verification
The good: A single model may assist several defensive stages, and Google describes staged access controls.[10][15]
The bad: Dual-use capability plus vendor-run results make casual adoption a poor experiment.[10][15]
Confidence: Moderate on reported benchmark results; low on production effectiveness.[10][15]
Dossier 04 · High for affected Android builds
Telegram Android calls: update before answering the mystery ring
What happened & verified timeline
NebuSec reported a private voice-call chain that could reach code execution after an Android recipient answered, with full-device control depending on additional chained bugs.[16]
The reported affected range is Telegram for Android 8.6.2 through 12.10.3, and the project repository records 12.10.4 as the fixed release boundary.[16][17][18][19]
Confirmed testing was limited to private voice calls on ARM64 Android phones; direct impact to iOS, desktop and group calls was not established.[16][20]
Exposure, wild observations & unknowns
No CVE or known in-the-wild exploitation was reported by the cutoff, and no public network or file indicators were available.[16][20]
The odd defensive advantage is that the interaction gate is visible: a call must arrive and be answered. The missing pieces are the complete chain, threat actor, victim count and what data would be reachable in a real compromise.[16][20]
Local / SMB implications
Any Android user or staff member on the reported build range is exposed to the stated call condition. The measured response is version-and-event triage, not declaring a phone compromised because it received a call.[16][20]
Immediate actions
Detection / verification
The good: The fixed version exists and the answer-the-call gate provides a clear temporary control.[16][20]
The bad: The public record does not fully document the chain, which limits precise detection.[16][20]
Confidence: High on the release boundary; moderate on the attributed exploit chain; low on observed abuse.[16][20]
Dossier 05 · Immediate credential hygiene
Gitee’s 26,400 live secrets: a denominator with teeth
What happened & verified timeline
A primary research report says a scan of 7,256,531 public Gitee repositories found 26,400 unique credentials that authenticated against vendor APIs at scan time.[21]
The count was deduplicated by raw secret value, so it is not a count of repositories, developers, victims or organizations.[21]
The report associated 12,242 of the credentials with 2025 commit dates, nearly half of the dataset.[21]
Exposure, wild observations & unknowns
At publication, revocation status had not been confirmed and third-party misuse was not established.[22][21]
The report says personal email domains made company attribution impossible at scale, and it did not name the enterprise platform tied to one organization-admin credential.[22][21]
The wild observation is longevity: some secrets traced back years, yet still authenticated during the scan. The unknown is what each key could reach and whether anyone abused it before revocation.[22][21]
Local / SMB implications
An SMB that ever placed an organization key in public Gitee should treat that key as exposed even if the line or commit was later deleted. Potential outcomes include unauthorized usage, charges, data access or resource changes, but this dataset does not prove which outcomes occurred.[22][21]
Immediate actions
- Revoke an exposed key at the issuing provider, replace it in every dependent service and apply least privilege; deleting it from Git history does not revoke it.[22][21]
- Inventory organization-owned repositories and their full history without opening, copying or testing anyone else’s credentials.[22][21]
Detection / verification
The good: The research carefully defines its numerator and validation method, and public secret-scanning tools exist.[22][21]
The bad: Live-at-scan credentials can provide direct access while ownership and misuse remain hard to establish.[22][21]
Confidence: High on the primary report’s methodology and counts; low on downstream misuse.[22][21]
Dossier 06 · Useful preview, bounded availability
GitHub’s npm firewall: a gate that only works in the route
What happened & verified timeline
GitHub announced its package firewall on October 20 and described it as a public preview for GitHub Enterprise Cloud, including data-resident Enterprise Cloud.[23][24]
The preview currently supports npm only and was free during preview; GitHub said general availability would use metered billing similar to Actions.[23]
Available controls include package-age cooldowns, malware and vulnerability advisory checks, attestation-downgrade checks and an exception workflow.[23][24]
Exposure, wild observations & unknowns
Coverage depends on routing metadata requests and downloads through the firewall; a direct public-registry remote can bypass the policy gate.[23][24]
The wild observation is architectural rather than malicious: the control can look enabled while unmanaged endpoints quietly take another road. Unknowns include general-availability pricing, support for other ecosystems and how policy accuracy changes during preview.[23][24]
Local / SMB implications
Eligible SMBs can add an install-time gate for developer machines, CI runners and AI-agent sessions. Most small organizations are not GitHub Enterprise Cloud customers, so the preview is not a universal answer and should not displace existing registry, lockfile and review controls.[23][24]
Immediate actions
Detection / verification
Dossier 07 · Urgent; active exploitation confirmed
Cisco ASA and FTD: the VPN door can crash the guard
What happened & verified timeline
Cisco says CVE-2026-76418 can let an unauthenticated remote attacker make an affected ASA or FTD device reload through the remote-access SSL VPN service, causing denial of service.[25][26]
Cisco reported active exploitation in October 2026, and CISA added the vulnerability to KEV on October 29 with a November 1 federal due date.[25][27]
Exposure requires a vulnerable release, reachable SSL VPN login service and secondary authentication in the applicable tunnel-group scope; a successful VPN login is not required.[25]
Exposure, wild observations & unknowns
Cisco says there is no workaround; disabling secondary authentication is only a temporary mitigation that lowers authentication protection.[25]
Public sources did not identify actors, targets, victim counts or unique indicators, and did not establish that every cited attempt produced a successful reload.[25][28]
The wild part is a defensive trade: the bridge control removes one authentication layer while buying patching time. The unknown campaign scale makes unexplained reloads worth preserving, not over-interpreting.[25][27]
Local / SMB implications
An exposed VPN appliance is both an access dependency and a failure point. A local firm may see an outage before it sees a clean security alert, while an MSP must inspect every active and standby peer rather than trusting a fleet label.[25][27]
Immediate actions
- Upgrade to the appropriate supported fixed release using Cisco’s branch guidance and Software Checker; do not infer safety from a major or minor version alone.[25]
- Before disruptive changes, preserve appliance clock, uptime, crash metadata, running configuration, VPN and AAA logs, and edge telemetry where operationally safe.[25][27]
Detection / verification
The good: Cisco published exposure checks and fixed releases; the documented direct impact is availability, not data theft.[25][27]
The bad: The service is commonly exposed, exploitation is confirmed and the fallback mitigation weakens authentication.[25][27]
Confidence: High on the flaw, exposure and exploitation status; low on campaign outcomes and scale.[25][27]
Dossier 08 · Critical self-managed GitLab boundary
Alpine’s GitLab incident: patched by label, vulnerable by runtime
What happened & verified timeline
Alpine reported that a newly registered account sent crafted CI configurations on October 20 and 21, causing eight GitLab worker crashes; four attempts progressed partway and failed at a later stage.[29]
Alpine found no evidence that attacker code ran but could not rule it out because decisive background-job, filesystem and outbound-network evidence no longer existed.[29]
The project’s upgrade to GitLab 19.3.6 did not fix its custom image because that image used standard Ruby instead of GitLab’s patched bundled Ruby.[29]
Exposure, wild observations & unknowns
GitLab lists the first fixed official builds as 19.2.8, 19.3.5 and 19.4.2, while Ruby recommends 4.0.9, 3.4.12 or 3.3.13 or later for the complete related fix set.[30][31]
Rapid7 reproduced code execution on an unpatched official 19.4.1 image and did not get execution from the same input on 19.4.2.[32]
The wild observation is a mutable image tag and a version label that both appeared reassuring while the active runtime remained vulnerable. Unknowns include whether execution ever succeeded and whether all potentially exposed tokens were rotated.[29][30][31]
Local / SMB implications
Anyone running a self-built GitLab image or source installation must inspect the Ruby that actually compiles expressions. A package version, container tag or downloaded image is evidence only when paired with digest, creation time and active runtime checks.[29][30][31]
Immediate actions
- Upgrade GitLab to the newest supported patch and ensure every running node and worker uses a fixed Ruby runtime; replace containers rather than updating an unused image on disk.[30][31]
- Preserve GitLab, Sidekiq, runner, reverse-proxy, container, database, host and network-flow evidence before destructive remediation.[29][30][31]
Detection / verification
- Use GitLab’s published detection guidance and correlate crashes, CI activity, temporary files, child processes, outbound connections, new accounts and runner changes.[29][30][31]
- Absence of a crash or web-log record does not clear the host where the missing evidence prevents exoneration.[29][30][31]
The good: Alpine disclosed its packaging error, rebuilt and checked independent package records.[29][30][31]
The bad: The exact evidence needed to settle success no longer exists, and mutable artifacts blurred remediation.[29][30][31]
Confidence: High on the attempts and patch boundary; low on whether code execution succeeded.[29][30][31]
Dossier 09 · Critical control-plane incident
KeyDrift in Cisco SD-WAN: patching closes a door, not the hideout
What happened & verified timeline
Cisco says CVE-2026-20127 affects Catalyst SD-WAN Controller, Manager and Validator regardless of configuration and has seen limited exploitation.[33]
Cisco Talos described KeyDrift as malware intended for persistent controller access and collection of control-session metadata and data-plane keying material.[34]
Talos assessed with high confidence that the activity infrastructure overlaps with Volt Typhoon’s Silent Train network, but that overlap is not a definitive statement that the operators are the same.[34]
Exposure, wild observations & unknowns
Cisco states there is no workaround and fixed software is required.[33]
The public KeyDrift report does not disclose victim count, intrusion dates, dwell time or confirmation that staged key material left a victim.[34]
The wild observation is a memory-resident foothold inside a trusted control plane. The central unknown is not whether patching matters; it is whether a pre-upgrade implant persists after the entry point closes.[33][34]
Local / SMB implications
Direct exposure is uncommon for an ordinary small office, but high for an SMB or MSP operating Catalyst SD-WAN control components. A shared provider control plane can extend the trust impact across managed customers.[33][34]
Immediate actions
Detection / verification
- Review control-plane authentication and peering events against authorized system IPs, maintenance windows and change records.[33][34]
- Use Cisco and Talos detections only after confirming that the relevant rules and telemetry are actually enabled; a clean hit list is not proof of a clean memory-resident controller.[33][34]
Recovery / escalation
The good: Patches, hardening guidance, log hunts and vendor support are available.[33][34]
The bad: The flaw is unauthenticated, configuration-independent and already exploited; patching alone may not evict persistence.[33][34]
Confidence: High on vulnerability and malware behavior; low on victim scale, exfiltration and final actor identity.[33][34]
Dossier 10 · Urgent after admin compromise
VMware ESX: the low score that erased high-value evidence
What happened & verified timeline
Broadcom rates CVE-2026-41709 at CVSS 2.7 and says a malicious administrator can perform certain ESX operations without them being logged.[35]
CrowdStrike reported that Warp Panda exploited the logging bypass as a zero-day in several U.S.-based intrusions, including legal-sector targets, as late as early 2026.[36]
CISA added the CVE to KEV on October 28 based on evidence of active exploitation.[37]
Exposure, wild observations & unknowns
The flaw requires administrator access and does not provide initial entry or new privilege by itself.[35]
The public record does not quantify victim organizations, affected hosts or the telemetry denominator, and Broadcom does not enumerate the exact operations that evade logging.[35][36]
The wild observation is that a “low” score accurately describes the prerequisite while missing the forensic consequence: after admin compromise, the audit trail itself becomes the target.[35][36]
Local / SMB implications
Small virtualized environments often concentrate many servers on one host and keep fewer independent logs. A logging gap can therefore remove a disproportionate part of the evidence needed to understand ransomware or espionage activity.[35][36]
Immediate actions
- Inventory affected ESXi and VCF builds, apply Broadcom’s fixed build for each supported branch, and do not rely on a workaround because none is available.[35]
- Restrict management interfaces to dedicated administration networks or controlled jump paths and preserve off-host evidence before rebooting when compromise is suspected.[35][36]
Detection / verification
The good: Patches exist across listed supported branches, and the prerequisite is already-admin access.[35][36]
The bad: There is no workaround, the hidden operations are undisclosed and exploitation attacks the evidence defenders need most.[35][36]
Confidence: High on the flaw and exploitation status; moderate on CrowdStrike attribution; low on public victim scale.[35][36]
Dossier 11 · Critical and actively exploited
PHP2Shell and exposed PAN-OS management: the firewall became the bridge
What happened & verified timeline
Palo Alto Networks says active exploitation targeted internet-exposed PAN-OS management interfaces affected by the PHP2Shell flaws.[38]
Dream Research reported artifacts from a campaign that rooted 25 firewall and management servers across the United States, Japan, Taiwan and South Korea, and Unit 42 says it independently verified the tooling and results.[39][40]
The affected PAN-OS surface is the HTTPS management web interface and XML API; GlobalProtect portal, gateway, Clientless VPN and Captive Portal are outside this specific issue.[38]
Exposure, wild observations & unknowns
The campaign’s recovered funnel was attacker-selected rather than a random prevalence sample, so the 25 rooted servers cannot be projected into a global victim rate.[40]
Public Unit 42 surfaces disagreed between approximately 0.02% impacted and less than 0.01% potentially affected, so this article does not choose or average those percentages.[39]
The wild observation is a management-plane compromise that can turn toward directory and identity infrastructure. Unknowns include named actor identity, complete downstream success and the unique-customer denominator.[38][39][40]
Local / SMB implications
For a local firm, the firewall is often the trust boundary. Root access to its management plane can expose configuration, VPN relationships and directory integrations even when public applications continue to look normal.[38][39][40]
Immediate actions
- Remove public internet access from PAN-OS and Panorama management interfaces, including management profiles on dataplane interfaces, and install the branch-specific fixed hotfix from Palo Alto’s current advisory.[38]
- Preserve configuration, system, identity and external-network evidence before rebooting or cleaning where feasible.[38][39][40]
Detection / verification
- Review management access and upstream network logs for unexpected external requests, child processes, outbound connections, files in web-served paths and directory-enumeration activity.[38][39][40]
- Correlate appliance evidence with Active Directory, LDAP, SSO, MFA, VPN and privileged-account logs; a clean appliance log alone is insufficient after possible root.[38][39][40]
The good: Palo Alto released hotfixes, confirmed the campaign and says the fixes interrupt the observed chain.[38][39][40]
The bad: The exposed surface is a high-trust management plane, and verified cases reached root with downstream identity risk.[38][39][40]
Confidence: High on exploitation, scope and the verified artifact set; low on global prevalence and named attribution.[38][39][40]

FAQ
Does a KEV listing prove a successful breach?
No. It is a prioritization signal for known exploitation, and CISA’s definition can include attempted exploitation. The Alpine case is the clearest warning: attempts were confirmed, success was not established, and missing evidence prevented exclusion.[29][27]
Can I trust a version string or container tag?
Not by itself. Verify the active kernel, Ruby runtime, image digest, appliance build and every HA or cluster peer. Mutable tags and stale nodes are recurring failure modes in tonight’s files.[2][29][31]
Does patching finish incident response?
No. Patching closes a vulnerable path. It does not evict an actor who already reached a firewall, hypervisor, SD-WAN controller, GitLab server, phone or downstream identity system.[34][36][39]
Why not publish exploit details?
This brief is defensive. It preserves exposure conditions, detection limits and safe recovery steps while omitting payloads, malicious requests and reproduction instructions.[41]
What should a small business do without a security team?
Start with reachability and trust: remove public management, update supported software, preserve logs, rotate exposed credentials from a clean device, and call the vendor, MSP or qualified incident responder when integrity is uncertain. For help reviewing a specific environment, use Contact Us; to find earlier coverage, use Search Articles.[25][21][38]
Methodology and transparency
The same-day gate began with fourteen rendered homepage cards dated October 29. Eleven standalone editorial subjects qualified; a weekly roundup, a webinar lead-generation page and contributed vendor opinion were excluded. Each dossier was rebuilt from direct public vendor, project, government or research sources in the supplied verified ledgers. Discovery reporting was used only where it carried a source-bounded fact unavailable in a reviewed primary page.[41]
Evidence states are deliberately visible in the prose: “reported,” “says,” “did not establish,” “at the cutoff” and “unknown” are not hedges to be polished away. Counts keep their denominators. Attribution signals remain signals. Conflicting percentages remain unresolved. Defensive recommendations are practical synthesis, not guarantees.
This article was written with AI assistance under human editorial direction. The writer is identified transparently as Jennifer Hudsen; AI assistance does not change the evidence standard, create publication authority or replace final human review. No malware, exploit code, exposed secret or offensive scanner was downloaded, tested or executed for this report.
Sources
- 1. CVE Record: CVE-2026-98432 — . Public source. Accessed 2026-10-29T23:35:11Z.
- 2. CVE-2026-98432.mbox — Linux kernel CVE team — . Public source. Accessed 2026-10-29T23:35:11Z.
- 3. Discovering and exploiting vulnerabilities in critical, real-world software with Claude — . Public source. Accessed 2026-10-29T23:35:11Z.
- 4. CVE-2026-98432 | Ubuntu — . Public source. Accessed 2026-10-29T23:35:11Z.
- 5. Red Hat CSAF VEX: CVE-2026-98432 — . Public source. Accessed 2026-10-29T23:35:11Z.
- 6. CVE-2026-98432 — Debian Security Tracker — . Public source. Accessed 2026-10-29T23:35:11Z.
- 7. CISA Known Exploited Vulnerabilities Catalog (machine-readable check) — . Public source. Accessed 2026-10-29T23:35:11Z.
- 8. Tricks from the Past deployed via signed ChatGPT and Claude binaries — . Public source. Accessed 2026-10-29T23:35:11Z.
- 9. Attackers Hide Malware Behind Signed ChatGPT and Claude Binaries — . Public source. Accessed 2026-10-29T23:35:11Z.
- 10. Gemini 4 Carbon: our next frontier model — . Public source. Accessed 2026-10-29T23:35:11Z.
- 11. Gemini 4 Carbon (High) — Artificial Analysis — . Public source. Accessed 2026-10-29T23:35:11Z.
- 12. SEC-bench Pro — . Public source. Accessed 2026-10-29T23:35:11Z.
- 13. ExploitGym — GitHub repository documentation — . Public source. Accessed 2026-10-29T23:35:11Z.
- 14. CWE-bench: a cybersecurity benchmark by Collinear AI — . Public source. Accessed 2026-10-29T23:35:11Z.
- 15. Google’s Fairwind Program: Cyber defense tools for trusted partners — . Public source. Accessed 2026-10-29T23:35:11Z.
- 16. Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls — The Hacker News. Public source. Accessed 2026-10-29T23:32:04.466587+00:00.
- 17. Update to 8.6.2 · DrKLO/Telegram@0abe454 · GitHub — Telegram Android source repository. Public source. Accessed 2026-10-29T23:32:40.491503+00:00.
- 18. update to 12.10.3 (7089) · DrKLO/Telegram@9552e55 · GitHub — Telegram Android source repository. Public source. Accessed 2026-10-29T23:32:41.573010+00:00.
- 19. update to 12.10.4 (7099) · DrKLO/Telegram@c848017 · GitHub — Telegram Android source repository. Public source. Accessed 2026-10-29T23:32:44.722567+00:00.
- 20. Telegram for Android Voice-Call RCE, Fixed in 12.10.4 | Ostorlab — Ostorlab. Public source. Accessed 2026-10-29T23:32:46.238708+00:00.
- 21. Scanning 7.25 Million Public Repositories on China's Largest Git Platform for Secrets | MongoDB — Ben Zimmermann / MongoDB. Public source. Accessed 2026-10-29T23:32:13.261709+00:00.
- 22. 26,400 Valid Cloud and AI Credentials Found Exposed in Public Gitee Repositories — The Hacker News. Public source. Accessed 2026-10-29T23:32:04.827666+00:00.
- 23. GitHub package firewall in public preview – GitHub Changelog — GitHub. Public source. Accessed 2026-10-29T23:32:20.877759+00:00.
- 24. Protecting endpoints with GitHub package firewall – GitHub Enterprise Cloud Docs — GitHub Docs. Public source. Accessed 2026-10-29T23:32:22.487877+00:00.
- 25. Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability — Cisco. Public source. Accessed 2026-10-29T23:32:54Z.
- 26. CVE-2026-76418 — CVE Program / Cisco CNA. Public source. Accessed 2026-10-29T23:32:54Z.
- 27. CISA Adds Two Known Exploited Vulnerabilities to Catalog — CISA. Public source. Accessed 2026-10-29T23:32:54Z.
- 28. New Cisco firewall zero-day exploited to crash SSL VPN devices — BleepingComputer. Public source. Accessed 2026-10-29T23:32:54Z.
- 29. GitLab security incident: attempted exploitation of CVE-2026-97229 — Alpine Linux. Public source. Accessed 2026-10-29T23:32:54Z.
- 30. GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 — GitLab. Public source. Accessed 2026-10-29T23:32:54Z.
- 31. Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 — Ruby. Public source. Accessed 2026-10-29T23:32:54Z.
- 32. CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab — Rapid7. Public source. Accessed 2026-10-29T23:32:54Z.
- 33. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa-EHchtZk — . Public source. Accessed 2026-10-29T23:35:11Z.
- 34. https://blog.talosintelligence.com/uat-11473-keydrift/ — . Public source. Accessed 2026-10-29T23:35:11Z.
- 35. https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017 — . Public source. Accessed 2026-10-29T23:35:11Z.
- 36. https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-legal-threat-landscape-report/ — . Public source. Accessed 2026-10-29T23:35:11Z.
- 37. https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog — . Public source. Accessed 2026-10-29T23:35:11Z.
- 38. https://security.paloaltonetworks.com/CVE-2026-109618 — . Public source. Accessed 2026-10-29T23:35:11Z.
- 39. https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/ — . Public source. Accessed 2026-10-29T23:35:11Z.
- 40. https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers?v=1029 — . Public source. Accessed 2026-10-29T23:35:11Z.
- 41. The Hacker News homepage — The Hacker News. Public source. Accessed 2026-10-29T23:31:11.132903+00:00.
