CISO Talk by James Azar
CyberHub Podcast
GitLab Exploited in the Wild, 9,300 AWS Keys Exposed, North Korea Poisons Rust & a Phone Call Breaches Apollo
0:00
-19:12

GitLab Exploited in the Wild, 9,300 AWS Keys Exposed, North Korea Poisons Rust & a Phone Call Breaches Apollo

From actively exploited GitLab infrastructure and thousands of live AWS credentials to poisoned open-source dependencies and help-desk social engineering

Good Morning Security Gang

Today’s show circles around one uncomfortable truth: your perimeter isn’t just the code you shipped or the firewall sitting at the edge of the network anymore. It’s every dependency you import, every credential somebody forgets inside a repository, every third party connected to the business, every CI/CD pipeline, and every help-desk employee authorized to reset an identity.

We’re leading with an actively exploited GitLab vulnerability that can allow an unauthenticated attacker to modify or delete public repositories. Researchers reproduced it within minutes of disclosure and almost immediately began seeing exploitation attempts. Then we have more than 9,300 AWS access keys discovered publicly exposed, with 88% still active when researchers checked. North Korean-linked attackers compromised the account of a maintainer behind a Rust package with more than 245 million downloads, while Apollo Global Management, an organization managing nearly $938 billion, was reportedly compromised through something considerably less sophisticated: attackers picked up the phone and socially engineered employees.

We’ll also cover an Iranian-linked attack that knocked a UK energy generator offline, Microsoft’s latest Azure security fixes, four CVSS 10.0 Cisco vulnerabilities, new banking malware campaigns, LockBit’s claim against U.S. Bancorp, an attack against Alation, another third-party breach affecting Toronto’s Hospital for Sick Children, and a $400 million child-privacy settlement involving TikTok and ByteDance.

Grab your coffee.

Coffee Cup Cheers, Security Gang.

Let’s get into it.

Today’s Cybersecurity Picture: Your Perimeter Has Changed

If there’s one thread connecting today’s stories, it’s that we have to redefine what we consider part of the enterprise attack surface.

A GitLab GraphQL endpoint can become a pathway into source-code integrity. An AWS credential forgotten in a Hugging Face dataset can become an administrative doorway into a cloud environment. A dependency downloaded automatically during a software build can become a North Korean supply-chain operation. And an employee sitting at a help desk can effectively become part of your identity perimeter because they possess the authority to reset credentials or MFA.

Security architecture needs to reflect that reality.

The perimeter didn’t disappear.

It expanded.

“Your perimeter isn’t the code you shipped. It’s every dependency, every leaked credential and every help-desk phone line touching your environment.” James Azar

GitLab Vulnerability Actively Exploited Against Public Repositories

We start with the most urgent story today. A critical GitLab vulnerability is now being actively exploited, potentially allowing unauthenticated attackers to modify or delete public projects through abuse of GitLab’s GraphQL functionality.

Researchers at WatchTowr reportedly reproduced the vulnerability within minutes of disclosure and subsequently detected real-world exploitation attempts hitting their honeypot infrastructure. This isn’t a theoretical vulnerability waiting for someone to weaponize it. Attackers are already probing for vulnerable systems.

GitLab has released fixed versions, including 19.2.4, 19.1.6, 19.0.8 and 18.11.11, covering affected Community Edition and Enterprise Edition branches. The exposure is particularly serious because no valid account is required to attack vulnerable public repositories.

For security teams, this needs to become a Monday-morning priority. Upgrade affected GitLab instances immediately and review web logs for requests containing the string @gl_introduced, which researchers identified as a probe signature associated with the activity.

If immediate patching isn’t possible, restrict unauthenticated access to the /api/graphql endpoint. For highly sensitive public repositories that can’t otherwise be protected, temporarily removing public access may be a legitimate emergency mitigation despite the obvious operational impact.

GitLab is source-of-truth infrastructure.

If an unauthenticated attacker can alter that source of truth, this isn’t simply another application vulnerability. It creates potential downstream software-supply-chain consequences.

Treat this vulnerability like the zero-day it is effectively functioning as, even if technically it isn’t one.

9,300 AWS Keys Found Publicly Exposed, 88% Were Still Active

The next story should get the attention of every cloud, DevOps, DevSecOps and AI engineering team.

Researchers at Truffle Security identified more than 9,300 AWS access keys publicly exposed between August 2022 and August 2026. As of August 10, approximately 88% remained active and valid.

The overwhelming majority, roughly 91%, representing approximately 8,482 credentials, were discovered inside Hugging Face datasets, model repositories, notebooks and Docker images. The remainder appeared across traditional code repositories, Git history, container registries and CI logs.

At least 817 companies were affected.

The privilege levels make the numbers even worse. Researchers identified 526 root access keys, representing unrestricted control of affected AWS accounts, and another 242 keys carrying administrator-level privileges. Combined, that means approximately 768 exposed credentials potentially provided extraordinary levels of control over corporate AWS environments.

The credential hygiene was equally concerning. The median exposed key was roughly five years old, the oldest had reportedly existed for 17 years, and only 13.7% had ever been rotated.

This is what happens when static credentials survive long after the architecture that originally justified them.

If you’re an AWS organization, particularly one with machine-learning or data-science teams using Hugging Face, scan those environments now. Eliminate root access keys wherever possible, revoke exposed credentials, replace long-lived static secrets with IAM roles and short-lived credentials, and implement automated secret scanning across code, model repositories, datasets and pipelines.

And turn on budget alerts.

They’re not a security control by themselves, but discovering that somebody suddenly spun up $100,000 worth of GPU infrastructure is a pretty useful tripwire.

North Korean Hackers Poison a Rust Package With 245 Million Downloads

Our third major story is a software-supply-chain attack that came dangerously close to becoming considerably worse.

Researchers linked a compromise of the Rust package ecosystem to Sapphire Sleet, a North Korean threat group. Attackers compromised the legitimate maintainer account behind arrayref, a widely deployed Rust crate with more than 245 million downloads and estimated presence across approximately 75% of Rust environments.

The attackers published malicious version 0.3.7, which introduced a fraudulent dependency called proc_macro—a lookalike designed to resemble the legitimate proc-macro2 package. Embedded inside was a malicious build script capable of retrieving platform-specific second-stage payloads over TLS while deliberately disabling certificate validation.

The attackers also poisoned versions of intermittent and append-only-vec and introduced several attacker-controlled packages as part of the broader operation.

Now for the good news.

The Rust security response team removed the malicious packages within approximately 86 minutes of discovery, and researchers found no evidence that the malicious crates were actually incorporated into a build.

That’s a successful ecosystem response.

But it also demonstrates the fragility of open-source trust. Attackers didn’t need to compromise 10,000 developers individually. They needed access to the account of one trusted maintainer sitting upstream from potentially millions of downstream systems.

If your build pipelines use arrayref, verify that version 0.3.7 wasn’t incorporated. Review dependency trees for the other identified malicious packages and examine CI/CD systems for unusual build-script behavior.

And if a dependency suddenly decides it needs to download an executable while disabling TLS certificate validation, your pipeline should treat that as hostile behavior until proven otherwise.

Apollo Global Management Breached Through a Phone Call

Now we get to the breach story that security leaders should take directly into their next executive or leadership meeting.

Apollo Global Management, the private-equity giant managing approximately $938 billion in assets, confirmed attackers gained access to cloud systems and obtained personal information including names, dates of birth, home addresses and Social Security numbers. The company had not publicly specified the total number of affected individuals or whether they were employees, customers or people associated with portfolio companies at the time of today’s episode.

But the attack vector is what matters.

According to threat researchers cited in the episode, attackers gained access between July 6 and July 10 through telephone-based social engineering. They called employees while impersonating IT help-desk personnel, convinced victims to visit a spoofed login portal and harvested their credentials.

No zero-day.

No sophisticated malware.

No advanced exploit chain.

A phone call.

“If your help desk will reset a credential based on a phone call alone in 2026, that’s not bad luck, that’s a process failure sitting one urgent-sounding phone call away from becoming next week’s breach notification.” James Azar

The activity appears connected to a broader campaign targeting private-equity and financial organizations, with other named targets reportedly including Blackstone, Bridgewater and Bain Capital. Some victims associated with the campaign have reportedly paid ransom demands reaching $750,000.

If your help desk can reset passwords or MFA over the phone, this story belongs in your tabletop exercises immediately.

Require strong identity verification for credential resets. Use callbacks to independently known telephone numbers—not numbers supplied during the interaction. Move privileged and high-value users toward phishing-resistant authentication such as FIDO2 security keys and passkeys.

And train the help desk specifically against these scenarios.

Not next year’s annual security awareness course.

Now.

My Reaction: Fix the Help Desk

Here’s my problem with this story.

Apollo manages close to a trillion dollars. Blackstone, Bridgewater and Bain operate at enormous scale. These organizations have security budgets larger than many companies’ entire IT budgets.

Yet attackers continue using essentially the same playbook that worked against MGM and Caesars years ago.

Call somebody.

Create urgency.

Pretend to be IT.

Reset an identity.

Get inside.

At some point, this stops being a story about sophisticated attackers and becomes a story about accountability for broken identity processes.

If your help desk can reset a high-value credential based primarily on a convincing telephone conversation in 2026, that’s not bad luck.

That’s a process failure waiting for the right caller.

Iranian-Linked Attack Knocks UK Energy Generator Offline for Four Days

A small UK energy generator was reportedly knocked completely offline for four consecutive days in July following a cyberattack attributed to actors linked to Iran’s Islamic Revolutionary Guard Corps.

The facility falls below the UK’s legal reporting threshold for major generators, and officials said the attack created no threat to the national electricity grid. Technical details regarding initial access were not publicly disclosed. The suspected objective appears to have been demonstrating capability rather than creating widespread physical disruption.

But there’s an important lesson here.

Regulatory thresholds aren’t risk thresholds.

A facility can be considered too small for certain reporting obligations and still represent meaningful critical infrastructure, operational dependencies and economic consequences.

OT and ICS organizations should inventory systems based on operational consequence, not merely regulatory classification.

Microsoft Patches 22 Vulnerabilities Across Azure Services

Microsoft released fixes covering 22 vulnerabilities across its cloud ecosystem, including four vulnerabilities carrying perfect CVSS 10.0 scores affecting Azure SQL Database, Azure Arc and Azure Managed Instance for Apache Cassandra.

Seven additional critical privilege-escalation vulnerabilities affect services including Azure and Exchange Online. Microsoft also corrected CVE-2026-69836, an Entra ID remote-code-execution zero-day, internally on the server side, meaning customers don’t need to take action for that particular issue.

That’s one of the benefits of consuming SaaS and cloud infrastructure: sometimes the vulnerability disappears because the provider patches the underlying platform before customers need to touch anything.

For the remaining vulnerabilities requiring customer action, however, review Microsoft’s guidance and prioritize remediation this week according to your deployed Azure services and exposure.

Cisco Fixes Four CVSS 10.0 Vulnerabilities

Cisco released fixes for nine vulnerabilities affecting products including Crosswork Data Gateway, Crosswork Network Controller and Secure Workload.

Four vulnerabilities received perfect 10.0 CVSS scores, including SQL injection and missing-authentication weaknesses affecting critical functionality. Cisco had not identified active exploitation at the time of today’s show.

But four CVSS 10 vulnerabilities in one security release deserve attention even without confirmed exploitation. Organizations operating Crosswork should move to the fixed releases, while Secure Workload customers should verify their versions against Cisco’s remediation guidance.

We’ve seen repeatedly how quickly high-severity network-infrastructure vulnerabilities attract nation-state attention. Don’t wait for the KEV entry to start patching.

Three Malware Campaigns Financial Institutions Should Track

Security operations teams, particularly those supporting financial organizations, should be tracking three active malware campaigns highlighted in today’s episode.

Manic is an Android spyware-grade banking Trojan targeting users across Ukraine, Russia and Europe. Grandoreiro, the long-running Brazilian banking Trojan, is using DLL sideloading through a fake Duplicate File Finder application in a new campaign targeting Mexico. ToxicPanda has evolved its capabilities and is now abusing Android wireless debugging for privilege escalation while distributing payloads through AWS-hosted storage infrastructure across multiple countries.

The broader trend is continued innovation around mobile financial fraud.

Banks shouldn’t treat compromised mobile endpoints purely as customer-security problems. Account telemetry, device intelligence and transaction analytics increasingly need to work together to identify when compromised devices become the entry point for financial fraud.

LockBit Claims U.S. Bancorp — But the Story May Be Fourth-Party Risk

LockBit added U.S. Bancorp, one of America’s largest banks, to its leak site and threatened to release allegedly stolen information within approximately two weeks.

U.S. Bancorp says its own systems, networks and data repositories show no evidence of compromise. Instead, the bank traced the claim to an incident affecting a contractor working for one of its vendors—potentially making this a fourth-party security incident.

Neither the vendor nor contractor had been publicly identified, and LockBit had not provided data samples validating its claim at the time of the episode.

So attribution and impact remain unconfirmed. But the architecture of the incident matters. Your third party has third parties.

And those fourth parties can still hold, process or access information belonging to your organization. Third-party risk management increasingly needs visibility beyond the vendor named on the contract.

Alation Confirms Cyberattack After Initially Reporting Availability Problems

AI data platform provider Alation, reportedly used by roughly half of the Fortune 1000, confirmed that an incident initially described as degraded availability was actually a cyberattack involving unauthorized activity on one of its systems.

The company says the immediate availability issue was resolved within approximately an hour, but later acknowledged the underlying security incident. At the time of today’s show, Alation had not publicly disclosed the initial-access mechanism or whether information was accessed.

There’s an incident-communications lesson here. Early information is frequently incomplete.

Organizations should avoid making overly definitive statements about outages before the investigation establishes whether malicious activity is involved.

Toronto SickKids Reports Third-Party Data Theft

Toronto’s Hospital for Sick Children disclosed a data-theft incident connected to third-party software affecting current and former employees, job applicants and personnel associated with related organizations.

According to the episode, no clinical systems or patient information were affected. Impacted individuals are being offered two years of credit monitoring.

The incident reinforces the third-party theme running through today’s show.

An organization can secure its primary clinical infrastructure and still inherit risk through software providers handling employee or operational information.

Third-party access isn’t separate from your attack surface.

It’s part of it.

TikTok and ByteDance Agree to $400 Million Child-Privacy Settlement

Finally, TikTok and ByteDance agreed to a $400 million settlement with the Department of Justice and FTC over alleged violations of the Children’s Online Privacy Protection Act involving underage users.

According to the episode, $300 million is payable immediately, with another $100 million contingent on the disposition of an earlier consent decree. The settlement is described as one of the largest recoveries under federal child-privacy law.

For security and privacy leaders, this reinforces something we’ve been watching for years: privacy compliance is increasingly becoming a material enterprise-risk issue rather than simply a legal checkbox.

Data governance, age assurance, retention and consent architecture have financial consequences when they fail.

James Azar’s CISOs Take

My takeaway from today’s show is that we need to stop defining the perimeter according to infrastructure diagrams. GitLab is part of the perimeter because it controls the integrity of our source code. Hugging Face is part of the perimeter when our AI and data-science teams publish models, datasets and notebooks containing AWS credentials. Open-source maintainers become part of the perimeter when their packages execute inside our build pipelines. The help desk is absolutely part of the perimeter because its employees can change identity controls that stand between an attacker and the enterprise. And our vendors’ contractors become part of the perimeter when they handle our data. The attack surface isn’t shrinking; our dependencies are multiplying faster than most security programs can map them.

The second takeaway is that security fundamentals remain incredibly effective when organizations actually enforce them. The Apollo attack didn’t require a breakthrough exploit. Static AWS keys don’t need an advanced nation-state operation to become dangerous. A poisoned dependency shouldn’t be able to silently download executables with TLS validation disabled. The solutions aren’t glamorous: phishing-resistant MFA, callback verification, short-lived credentials, dependency controls, secrets scanning, third-party visibility and aggressive patching. We spend enormous amounts of time talking about AI, autonomous attacks and zero-days, and we should. But attackers will continue taking the easiest route available. Make the basics difficult to defeat before spending another dollar making the complicated stuff harder.

Leave a comment

Action Items

  • Patch affected GitLab Community and Enterprise Edition instances immediately to 19.2.4, 19.1.6, 19.0.8, 18.11.11 or another vendor-supported fixed release.

  • Hunt GitLab web logs for @gl_introduced activity and investigate potentially unauthorized GraphQL requests.

  • Restrict unauthenticated GraphQL access where immediate GitLab patching isn’t possible, and consider temporarily removing public repository access for highly sensitive environments.

  • Scan Hugging Face repositories, datasets, notebooks and containers for AWS credentials alongside traditional source-code repositories and CI/CD systems.

  • Eliminate AWS root access keys wherever possible and immediately revoke or rotate any exposed static credentials.

  • Replace long-lived AWS credentials with IAM roles and short-lived authentication and enforce automated credential rotation.

  • Enable AWS budget and anomaly alerts as an additional tripwire for unauthorized cloud-resource consumption.

  • Audit Rust dependency trees for the malicious arrayref 0.3.7 release and associated packages identified in the campaign.

  • Flag dependencies that disable TLS validation or unexpectedly download executable content during builds for automatic security review.

  • Require independent identity verification for help-desk password and MFA resets, including callback procedures using known-good contact information.

  • Accelerate phishing-resistant MFA deployment for executives, administrators, finance personnel and other high-value identities.

  • Run help-desk-specific social-engineering exercises now, rather than relying solely on annual enterprise awareness training.

  • Inventory smaller OT and ICS facilities based on operational consequence rather than regulatory reporting thresholds.

  • Review Microsoft’s August Azure security fixes against services deployed in your environment and prioritize the critical customer-action items.

  • Patch Cisco Crosswork and Secure Workload deployments affected by the newly disclosed critical vulnerabilities.

  • Ensure financial-sector SOC teams are tracking Manic, Grandoreiro and ToxicPanda activity across mobile and endpoint telemetry.

  • Expand third-party risk mapping to material fourth parties that store, process or access organizational information through primary vendors.

  • Review incident-communications procedures so availability incidents aren’t prematurely characterized before malicious activity has been excluded.

  • Validate third-party software access to HR and employee information and ensure breach-notification obligations are contractually defined.

  • Redefine your enterprise attack-surface inventory to include code repositories, AI/ML platforms, dependencies, identity-reset processes, CI/CD infrastructure, SaaS integrations and downstream vendors.

Get the basics right. Make the easy path harder.

Stay Cyber Safe.

Thanks for reading CISO Talk by James Azar! This post is public so feel free to share it.

Share

Discussion about this episode

User's avatar

Ready for more?