The Hacker Diaries — Featuring Jennifer Hudsen: Case File No. 014

1. Artifactory: the keys to the warehouse

EnterpriseAdministratorSupply chainAct tonight

What happened

JFrog disclosed CVE-2026-82329 on August 28, 2026: a Critical CVSS 3.1 score of 9.8 improper-authentication flaw that may let an unauthenticated network attacker gain administrative privileges under default configuration.^[1][3]

On September 1, watchTowr said its sensors were already seeing attackers mint administrative tokens; it later told The Register that a small number of source IP addresses in varying geographies had reached multiple honeypots, without broad scanning or mass exploitation at that point.^[4][5]

Verified evidence and timeline

JFrog published six branch-specific fixed builds on August 28: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20.^[1][2][3]

The affected half-open ranges in the CNA record are versions before 7.111.21; 7.117.0 through before 7.117.28; 7.125.0 through before 7.125.20; 7.133.0 through before 7.133.29; 7.146.0 through before 7.146.38; and 7.161.0 through before 7.161.20.^[3]

JFrog says affected Cloud environments were already fortified and require no customer action, while self-hosted customers must upgrade on their applicable branch.^[1]

Exposed systems and in-the-wild evidence

The urgent predicate is narrower than “any company using JFrog”: a self-hosted affected build, vulnerable default behavior, and network reachability from an untrusted party. Internet exposure is the brightest red light, but internal reachability still matters when contractors, low-trust users, or a compromised workstation can touch the service. Confirm every node, region, pod, load balancer, and federation peer; a single updated UI node does not prove the fleet is clean.

CVE-2026-82329 was absent from CISA’s Known Exploited Vulnerabilities catalog version 2026.09.01 released at 19:22:46Z on September 1, but catalog absence does not rebut newer researcher telemetry.^[38][4]

Unknowns

No reviewed primary source published a production-victim count, named actor, unique indicator set, or confirmed downstream package-poisoning event. JFrog had not publicly confirmed the exploitation report by the cutoff. The narrower configuration explanation circulating in press is not an authoritative safe-harbor statement for an affected build.

Who is affected

• Consumers: no direct patch unless you operate Artifactory; risk is indirect through software you receive.
• Small business: managed developers and software shops should ask whether a vendor or internal team self-hosts Artifactory.
• Administrators: inventory reachable nodes, preserve logs and configuration, restrict exposure, upgrade, and audit privileged changes.
• Developers: verify package and image provenance if the repository enters the incident window.
• Enterprise: treat confirmed administrative compromise as a supply-chain and identity incident, not just a server patch.

Immediate actions, detection, and recovery

1. First, preserve Artifactory, Access, router, reverse-proxy, load-balancer, identity-provider, and CI/CD logs from August 28 through containment before retention or rebuilds erase them.^[1][2]
2. Second, restrict untrusted reachability and upgrade every active instance to the applicable fixed build or a newer supported patched release after compatibility testing.^[1][6]
3. Third, use the documented access-security-audit.log fields to review unexplained token creation, privileged users or groups, permission changes, and federation or security-configuration changes.^[6]
4. If compromise is suspected, patching is only containment: revoke unknown tokens, rotate exposed CI/CD and signing credentials from a clean system, compare artifact digests with known-good provenance, and rebuild the management plane when integrity cannot be established.^[1][6][19]

Confidence: High on the vulnerability and fixed builds; moderate on current exploitation because the public sensor evidence originates with watchTowr and is not independently reproduced.

2. BREEZE COMET: payment fraud after the quiet work

EnterpriseFinanceIdentityMonitor now

What happened

Google Threat Intelligence Group tracks BREEZE COMET, formerly UNC5669, as a financially motivated cluster seen in Brazilian financial-services, retail, and e-commerce compromises beginning in 2024.^[7]

In one unnamed case, GTIG says the actor executed two waves of hundreds of fraudulent transactions within 24–48 hours of reaching core financial applications, while at least one heist netted assets worth tens of thousands of U.S. dollars.^[7]

Verified evidence and timeline

CrowdStrike says overlapping PLUMP SPIDER activity has targeted Brazilian financial entities since at least September 2023; GTIG’s own Mandiant investigations begin in 2024, and the two observation clocks should not be collapsed into one exact campaign start.^[7][9]

GTIG says the operational model requires access to Brazil’s National Financial System Network through an authorized entity, usable mutual-TLS transaction credentials, persistent access to multiple identity accounts, and detailed knowledge of transfer processing and anti-fraud controls.^[7]

Exposed systems and in-the-wild evidence

The danger is not a magic “bank malware” button. It is the attacker’s accumulation of ordinary but powerful footholds: remote support access, privileged identity, cloud and CI/CD secrets, transaction certificates, payment APIs, branch or retail connectivity, and knowledge of how a transfer should look. A small business supplying software, point-of-sale services, or IT access to a financial client may sit on that path even if it never moves money itself.

GTIG reports activity around Pix, STR, and Boleto systems, but the public report does not identify which rail carried the unnamed hundreds-of-transactions case.^[7]

GTIG found evidence consistent with LLM assistance in recovered scripts, while Trend Micro separately observed AI-agent-like scripting in a related Brazil-finance cluster; neither source identifies a model or proves autonomous execution of the fraud.^[7][10]

Unknowns

The exact victim, date, transaction count, attempted-versus-settled split, payment rail, gross loss, recovery, and telemetry denominator are not public; vendor labels overlap, but BREEZE COMET, PLUMP SPIDER, and SHADOW-AETHER-064 are not proven legal identities, and municipal infrastructure seen outside Brazil is not a confirmed victim list.^[7][9][10]

Who is affected

• Consumers: watch accounts and respond through the financial institution’s official channel; this report does not identify a general consumer infection.
• Small business: protect remote support, payroll, merchant, and banking access with independent callback procedures.
• Administrators: isolate payment workloads, identity tiers, cloud secrets, and branch networks.
• Developers: remove plaintext credentials from pipelines and control who can deploy to payment-connected systems.
• Enterprise: correlate transaction anomalies with identity, certificate, HSM, cloud, and endpoint events.

Immediate actions, detection, and recovery

1. First, centralize and log access to transaction certificates, HSM or KMS material, cloud tokens, and payment API credentials, then remove hard-coded secrets and reduce standing privilege.^[7][8]
2. Second, microsegment payment-connected workloads from office, branch, retail, and general server networks; restrict unnecessary lateral and outbound paths.^[7]
3. Third, correlate unusual transaction volume, timing, destinations, or signing patterns with privileged logons, new remote tools, secret access, service-account changes, and payment configuration changes.^[7][8]
4. During an incident, preserve off-host logs, isolate affected payment and identity systems, revoke credentials based on verified exposure, reconcile attempted and settled transactions, eradicate persistence, and restore heightened monitoring before reconnecting.^[7][8][19]

Confidence: High on GTIG’s published model and sector focus; moderate on the unnamed fraud outcome because public evidence is detailed but not independently reproducible.

3. Poisoned website themes and the old-iPhone trap

ConsumerDeveloperWebsite adminUpdate tonight

What happened

Socket identified 13 Composer theme packages across five Packagist vendor namespaces that it says carried trojanized browser-side JavaScript for Vietnamese OphimCMS and KKPhim streaming sites.^[11]

Socket describes two distinct branches: mobile advertising and gambling redirects, and a version-gated iPhone exploit chain intended to install spyware; the redirect itself should not be described as the infection mechanism.^[11]

Verified evidence and timeline

The analyzed iPhone path targeted iPhone XS through iPhone 16 devices running iOS 18.4 through 18.6.x, and Socket found no matching offset tables for iOS 18.7 or iOS 26.^[11]

The WebKit entry bugs were CVE-2025-31277 and CVE-2025-43529; Apple’s records place fixes in iOS 18.6 and iOS 18.7.3 or 26.2 respectively.^[11][12][15]

At the cutoff, Apple’s newest supported releases in the relevant branches were iOS 26.6.1 for iPhone 11 and later and iOS 18.7.10 for iPhone XS, XS Max, and XR, both released August 17, 2026.^[13][14]

Exposed systems and in-the-wild evidence

A site operator is exposed if one of the exact malicious themes or copied assets remains deployed or cached. A visitor still needs to meet platform, referrer, model, version, and exploit-success gates. That distinction matters: a malicious delivery point is serious, but it is not a census of infected phones.

Socket reported live delivery infrastructure, an August 12 full-chain redeployment, and an August 17 loader rotation, but published no confirmed visitor-infection count, stolen-cryptocurrency total, or forensic victim case.^[11]

Google independently documents DarkSword use by multiple actors beginning in November 2025, but Socket says this Packagist campaign only overlaps at WebKit entry and staging while its final kernel stage differs.^[11][15]

Unknowns

Successful exploitation in this package campaign remains publicly unproven; the kernel race is not publicly mapped to CVE-2026-43655, CVE-2025-43510, or CVE-2025-43520, and the numbers of affected sites, visitors, successful implants, and wallet losses are unknown.^[11][15]

Who is affected

• Consumers: owners of supported iPhones should take the newest offered update; highest concern belongs to people who visited affected sites on the targeted old builds.
• Small business: update managed phones and ask website vendors to inventory Composer locks and deployed assets.
• Administrators: preserve logs and exact deployed assets first; then remove confirmed themes, purge caches/CDNs, and investigate browser-facing assets.
• Developers: review dependencies and namespace provenance; a removed registry entry does not delete deployed code.
• Enterprise: high-risk personnel may consider Apple Lockdown Mode after updating, with its usability tradeoffs.

Immediate actions, detection, and recovery

1. First, install the newest iOS release the supported device offers rather than stopping at the first version that fixed one known stage.^[12][13][14]
2. Second, operators should preserve relevant logs and exact deployed assets, inventory composer.lock and deployed assets for the 13 exact packages, then remove confirmed-malicious themes and purge template, browser, and CDN caches.^[11]
3. Third, inspect theme JavaScript and administrative custom-code fields for Socket’s published indicators and correlate web or CDN logs with platform and referrer gates; a clean search is not proof of no exposure.^[11]
4. If wallet recovery material may have been exposed, use a clean updated device and the wallet provider’s official process to move assets and replace the wallet or seed; changing an app password does not invalidate an exposed seed phrase.^[11][19]

Confidence: High on Apple’s release facts; moderate on campaign behavior because Socket is the sole public technical investigator.

4. The recruiter who brought a project—and a passenger

DeveloperConsumerSmall businessInvestigate exposure

What happened

Kaspersky says the cluster it calls Mirage Kitten used fake recruiter approaches and trojanized coding challenges to deliver two newly documented JavaScript-family remote-access trojans, NodeRabbit and PollCat.^[16]

Kaspersky attributes the campaign to Mirage Kitten with high confidence; Mandiant separately assessed related UNC1549 activity as tied to an Iran-based actor with moderate confidence, which does not prove direct government control of this operation.^[16][18]

Verified evidence and timeline

Kaspersky recovered three NodeRabbit variants from systems in Afghanistan, Egypt, and Ethiopia and reports affected sectors including fintech, aviation, and aerospace.^[16]

Related infrastructure registrations span May 15 through July 3, 2026, but those dates bound preparation or discovery and do not establish a campaign start or compromise date.^[16]

Exposed systems and in-the-wild evidence

Both malware families contain Windows, Linux, and macOS logic, yet Kaspersky did not publish the operating systems of the three recovered systems, so cross-platform capability is not proof of observed infection on all three families.^[16]

The prerequisite is beautifully ordinary and therefore dangerous: receive an archive, trust the recruiter, and run the project in a Node.js/npm development environment. The packages were bundled with the archive rather than published to the public npm registry. This was not reported as a zero-click exploit or registry compromise.

PollCat begins its first command-and-control polling during application startup before one-time-password entry; a valid recruiter-supplied OTP or JWT is required for the described persistence attempt and an additional worker instance, not for the first execution.^[16]

Unknowns

No victim organizations, complete victim count, stolen-data outcome, or confirmed PollCat victim geography is public. Multi-scanner submissions from several other countries are submissions, not victims. AI generation of the lure is speculation, not a finding.

Who is affected

• Consumers: job seekers and independent developers should verify recruiters outside the message thread.
• Small business: engineering managers should provide disposable assessment environments without company secrets or mounted repositories.
• Administrators: hunt for unexpected Node.js processes, persistence, VS Code extensions, Git-hook changes, and unusual egress.
• Developers: inspect the full project and bundled dependencies before execution; never run unknown tests on the daily workstation.
• Enterprise: connect recruiting-security education to endpoint, identity, repository, and cloud telemetry.

Immediate actions, detection, and recovery

1. First, identify anyone who received or ran an unsolicited coding test and preserve the message, URL, archive metadata, project tree, shell history, and endpoint telemetry.^[16][19]
2. Second, isolate exposed endpoints and hunt for detached Node.js processes, hidden project-local payloads, new Run keys or scheduled tasks, cron or LaunchAgent entries, WSL launchers, unfamiliar VS Code extensions, modified Git hooks, and unusual egress.^[16]
3. Third, scope repositories, tokens, SSH material, browser sessions, cloud credentials, and developer secrets reachable from the endpoint, then revoke exposed access from a clean device.^[16][19]
4. Recover by removing every confirmed persistence mechanism or reimaging from trusted media when eradication cannot be demonstrated; restore only reviewed repositories and configurations, then monitor for recurrence.^[16][19]

Confidence: Moderate-to-high on Kaspersky’s observed recoveries and code analysis; moderate on attribution; low on any unstated theft outcome.

5. METR: free credits, expensive silence

DeveloperSmall businessCloudAct this week

What happened

METR says an external attacker exploited a fail-open authentication defect in an agent dashboard on a researcher’s personal internet-accessible EC2 instance, prompted an agent to disclose a general-access API key, and added an SSH key for persistence.^[20]

The key was used for about three weeks and consumed credits with an estimated commercial value of approximately $600,000, but the provider had granted those credits free, so the figure is not a $600,000 cash bill, direct loss, or proven attacker profit.^[20][21]

Verified evidence and timeline

The researcher deployed the instance in March 2026; the exact compromise, detection, and revocation dates were not disclosed, and METR’s remediation description was stated to be accurate as of July 30, 2026 before the August 31 disclosure.^[20]

METR suspects certificate-transparency or recently registered-site monitoring may have led the attacker to the dashboard, but it did not prove that discovery path.^[20]

Exposed systems and in-the-wild evidence

This is a small-business-shaped failure: an experimental public app, a personal cloud account, a long-lived organization credential, authentication that failed open, and no clean per-key cost ceiling. Normal high-volume evaluations and missing rate-limit visibility made the abuse resemble business as usual. Free credits removed the billing alarm that might have ended the party early.

METR reports that its investigation and a compromise assessment by security consultant Calif found no compromise beyond one public-model API key and no access to sensitive category 3 or 4 information, but no separate consultant report, provider statement, or logs were published.^[20]

Unknowns

The attacker, origin, infrastructure, workload, model provider, model mix, token totals, source IPs, and realized provider cost remain unknown. The separate May probing incident should not be merged with the March key theft; no shared actor is established.

Who is affected

• Consumers: no customer breach is established; the lesson is to treat “free” account value as something that can be stolen.
• Small business: public demos and personal cloud sandboxes need the same authentication and secret rules as paid production.
• Administrators: inventory keys by owner, workload, scope, value, expiry, and revocation path.
• Developers: keep raw provider credentials outside agent-readable context and fail closed when authentication dependencies break.
• Enterprise: alert per key and workload, including rejected and rate-limited requests—not only account totals.

Immediate actions, detection, and recovery

1. First, move public agent demos into managed isolated accounts with no path to internal data and no company key on a personal host.^[20][22]
2. Second, give each workload a separate short-lived or tightly scoped credential, store it in a managed secrets system, and test from an external client that missing or broken authentication produces an explicit denial.^[20][22]
3. Third, alert on per-key request count, token consumption, estimated retail value, unfamiliar source networks, new model use, errors, and rate-limited attempts, with a named human owner and rehearsed revoke path.^[20]
4. After a host compromise, preserve evidence, then revoke user sessions, OAuth grants, SSH keys, cloud credentials, refresh tokens, and every secret present; rebuild from a trusted image and review downstream provider use.^[20][19]

Confidence: High on what METR publicly said and on the value qualifier; moderate on scope because the public record lacks independent forensic artifacts.

6. GuardBreaker: the note that tries to scare the analyst

EnterpriseAI securitySOCArchitecture

What happened

ESET says it found a safety-sensitive weapon-related comment inside a malicious VBS script linked to UAC-0099 and named the apparent anti-analysis idea GuardBreaker.^[23][24][25]

ESET assesses that the inert comment was intended to make some LLM-assisted analysis workflows stop or refuse, but the public disclosure names no affected model or product and provides no controlled result or success rate.^[23][24]

Verified evidence and timeline

ESET reports one unnamed victim in Ukraine and says the script’s ordinary function was to install MATCHBOIL, a loader it associates with UAC-0099.^[23][25]

CERT-UA independently documents repeated UAC-0099 use of MATCHBOIL in earlier campaigns, while ESET assesses with medium confidence that UAC-0099 is aligned with Russian interests.^[26][27]

Exposed systems and in-the-wild evidence

The VBS runtime ignores the comment. The proposed target is the surrounding analysis architecture: a pipeline that mixes attacker-controlled text with trusted instructions, relies on one language model, and treats refusal or silence as “clean.” Conventional parsing, signatures, sandbox behavior, EDR telemetry, and human review are not shown to be defeated.

No public source reviewed identifies a production AI security system that refused, truncated analysis, or missed this sample because of the embedded comment.^[23][24][25]

Unknowns

The victim’s sector, exact model, model version, prompt wrapper, context length, fallback logic, and operational outcome are unknown. Intent is ESET’s assessment from placement and content. Any claim that safety guardrails themselves are universally vulnerable would outrun the evidence.

Who is affected

• Consumers: little direct action; do not paste suspicious files into public AI chats.
• Small business: teams using AI to triage email, documents, or code should keep human and deterministic checks.
• Administrators: log refusals, truncation, schema failures, and model/version changes.
• Developers: separate untrusted artifact content from system instructions and validate outputs before tools act.
• Enterprise: red-team the exact production pipeline and require fail-safe fallback across model and non-model controls.

Immediate actions, detection, and recovery

1. First, treat every file, comment, email, webpage, and retrieved document entering an AI workflow as adversarial data and clearly isolate it from trusted instructions.^[28][29]
2. Second, treat refusal, truncation, empty output, or schema failure as suspicious and route it to deterministic analysis and human review rather than a benign verdict.^[28][29]
3. Third, preserve the original artifact for evidence while creating a controlled derivative that separately labels or removes non-executable comments for one analysis pass.^[23][24][28]
4. Fourth, red-team the actual model, system prompt, context window, file types, tools, permissions, and fallback logic; log mismatches between LLM output and conventional controls.^[28][29]

Confidence: High that ESET observed the comment and linked the script to UAC-0099; low that the technique successfully disrupted a production model.^[23][24][25]

7. Langflow and Rails: two critical doors, two different rooms

AdministratorDeveloperCloudAct tonight

What happened

CVE-2026-0768 is a Langflow code-injection flaw scored CVSS 3.0 at 9.8 by ZDI, while CVE-2026-66066 is a Rails Active Storage and libvips chain scored CVSS 4.0 at 9.5 in the CNA record.^{[30][31][34][35]}

VulnCheck reported first-time exploitation of both flaws in researcher-operated canaries: Langflow requests performed reconnaissance and credential probing, while the Rails activity established outbound command-and-control.^[32][36]

Verified evidence and timeline

For Langflow, the CNA identifies version 1.4.2 as affected with default status unknown rather than publishing a complete affected range or fixed version.^[31]

Langflow 1.10.1 removed runtime execution from validate_code, and version 1.12.0 was the newest release at the cutoff, published September 1, 2026 at 21:16:20Z.^[33][30][31]

For Rails, affected Active Storage ranges are below 7.2.3.2; 8.0 through below 8.0.5.1; and 8.1 through below 8.1.3.1, with fixed releases 7.2.3.2, 8.0.5.1, and 8.1.3.1.^[34][35]

Exposed systems and in-the-wild evidence

VulnCheck’s Langflow post reported more than 50 detections that morning, traffic primarily sourced from Russia, and hits on United Kingdom canaries; the requests sought environment variables and local files associated with Langflow, OpenAI, AWS, SSH, and shell history.^[32]

VulnCheck’s Rails telemetry reached canaries in Singapore, Israel, and the United Kingdom from one source IP address in France and established command-and-control to a host in Israel.^[36]

Neither CVE appeared in CISA KEV catalog version 2026.09.01 released before the cutoff; that absence does not override the later canary evidence.^[38][32][36]

Exposure and unknowns

Langflow exposure requires vulnerable validation behavior reachable by attacker-controlled requests without an effective gate; service privilege and mounted secrets determine impact. Rails exposure requires Active Storage using libvips and an untrusted image-upload path. These are different products, codebases, and recovery jobs despite sharing a headline.

No reviewed source names a compromised production victim, confirms stolen credentials, publishes a complete event denominator, attributes an actor, or links ransomware. Event counts are not victim counts, and internet-exposure estimates are not compromise totals.

Who is affected

• Consumers: no direct device patch; risk arrives through services they use.
• Small business: ask web or AI-app vendors whether Langflow or vulnerable Rails Active Storage is exposed.
• Administrators: preserve edge, runtime, cloud, and storage evidence, remove public reachability, then deploy fixed/current builds everywhere.
• Developers: identify actual package/runtime versions and untrusted routes; commit dates and banners are not deployment proof.
• Enterprise: rotate secrets by process reachability and inspect downstream use, sessions, cloud, object storage, and identity.

Immediate actions, detection, and recovery

1. For Langflow, preserve proxy, API, process, container, DNS, cloud, secret-store, configuration, and exact-image evidence; then restrict the service to trusted management networks, disable public reachability and auto-login where possible, upgrade every replica to a current supported release containing compile-only validation, and verify no stale image remains.^[30][31][33]
2. Hunt preserved Langflow telemetry for code-validation requests that align with child processes, filesystem writes, unexpected outbound traffic, or credential use.^[32][19]
3. For Rails, preserve Active Storage records, object versions, upload and representation logs, job logs, cloud audits, configuration, and exact deployed versions before cleanup or routine retention changes them.^[34][35]
4. Then deploy Rails 7.2.3.2, 8.0.5.1, 8.1.3.1, or a later applicable release; verify every web and job worker restarted with supported libvips and ruby-vips controls, and use the Rails forensic repository to distinguish staged blobs, executed variant records, and returned data while remembering that a clean scan is not proof.^[34][37]
5. If either service may have been exploited, isolate and rebuild the workload, rotate every secret readable by the process, revoke old sessions and signing material, and hunt downstream use after rotation.^{[19][32][34][36][37]}

Confidence: High on product scope and fixed/current releases; moderate on exploitation because the strongest public evidence is researcher-canary telemetry, not named production cases.