FearsOff Cybersecurity

Protecting the World’s Largest Crypto Exchanges & Financial Institutions 🛡️ Stay Secure and Turn your FearsOff 🛡️

[Kirill Firsov @k_firsov]

php2shell

Tomorrow is a helluva day.

[FearsOff Cybersecurity @FearsOff]

Japan’s ruling party says the country is in “a state of emergency in cyber space.” Two stories from the past week show why, and they are more connected than they look.

On October 9, Japan’s National Cybersecurity Office issued a nationwide advisory after a wave of breaches at major consumer brands:

• Monogatari (Yakiniku King): 10.79 million app member records
• Daiichikosho: up to 8.72 million customers
• BOOK OFF: up to 6.43 million member records

Japan has passed 500 reported incidents this year, already above 2025’s full-year total.

The advisory focuses on three areas: web-system vulnerabilities, supply chains, and data management. Daiwa Securities’ exposure came through a contractor’s server.

On October 14, Microsoft and Health-ISAC, with Japan’s JC3 among the partners, disrupted YAM Store, CoGUI and Iron Man under a Florida federal court order. Since January, these services enabled more than 1 billion malicious messages targeting over 75,000 organizations. CoGUI was used heavily against victims in Japan.

Here’s the link: names, emails and phone numbers stolen in breaches are exactly what phishing kits run on. That’s why the breached Japanese companies are warning customers about fraudulent emails and calls.

YAM Store’s supply chain matters too. It hijacked Microsoft 365 and Azure for Education tenants and revived dormant nonprofit websites to fraudulently obtain cloud accounts, then resold them to phishing operators.

Two lessons:

The member apps and vendor systems holding your customer data are the target. Test them the way attackers will, including the ones your contractors run.
Every tenant, domain and account you’ve forgotten is inventory in someone else’s store.

One question for your team this week: do you know every system holding customer data, and every cloud tenant and identity your organization still owns?

#Japan #Cybersecurity #PhishingAsAService #CloudSecurity #ThreatIntelligence #FearsOff

[FearsOff Cybersecurity @FearsOff]

On October 11-12, hundreds of supermarkets across France were reportedly affected by a cyberattack targeting connected refrigeration systems.

Major retailers, including Carrefour, Intermarché, E. Leclerc, Monoprix, and Coopérative U, confirmed affected stores.

The consequences were serious:

Refrigeration temperatures were remotely manipulated, leading to significant food losses.

Fires linked to the attack were confirmed by the Paris prosecutor.

Intermarché estimated nationwide losses in the tens of millions of euros.

According to Danfoss, many affected controllers were legacy systems no longer receiving security updates.

How did it happen?

According to media reports, attackers exploited remotely accessible refrigeration controllers to trigger extended defrost cycles, potentially raising temperatures to 50°C. The exact attack vector remains under investigation.

This incident highlights a critical OT security risk:

Systems designed to control physical environments can become attack surfaces when exposed to the internet.

And unlike traditional IT incidents, the consequences can include physical damage, operational disruption, and substantial financial losses.

At FearsOff, we believe OT security starts with understanding your exposure, identifying vulnerable systems, and securing remote access before attackers exploit it.

The question for every organization operating connected infrastructure is simple:

If your refrigeration, HVAC, or industrial controllers were exposed to the internet today, would you know?

#OTSecurity #ICSSecurity #CyberPhysicalSecurity #CriticalInfrastructure #RetailSecurity #OffensiveSecurity #FearsOff

[FearsOff Cybersecurity @FearsOff]

318 GitHub repositories compromised in 16 minutes.

On October 8, attackers used compromised maintainer credentials to inject malicious GitHub Actions workflows disguised as security audits.

StepSecurity documented two compromised accounts:

One used to modify 27 repositories.

Another used to modify 318 repositories in just 16 minutes, including an Uber-owned repository where the malicious workflow executed.

How the attack worked:

1. Compromised access: Attackers used legitimate maintainer credentials, potentially obtained through a leaked GitHub personal access token.

2. Workflow injection: Malicious files such as security-audit.yml were committed directly to default branches. No pull request. No code review.

3. Secret exfiltration: The workflows searched repository files and git history for 13 credential patterns, including AWS, OpenAI, Anthropic, and GitLab keys, then sent collected matches to an attacker-controlled IP over HTTP.

The scale was even larger.

By October 9, Socket reported that more than 500 accounts had committed malicious workflows to tens of thousands of repositories.

GitGuardian separately identified 772 affected public repositories in an earlier campaign wave. By October 5, only 16% had been cleaned in public history.

The real security failure?

Attackers didn't need to exploit application code. They abused trusted developer access to turn CI/CD automation into a credential-stealing mechanism.

And deleting secrets from the latest commit doesn't remove them from git history.

What security teams should prioritize:

Require reviews for workflow changes.

Enforce least-privilege CI/CD permissions.

Restrict unnecessary outbound network access.

Revoke compromised tokens and rotate exposed credentials.

Scan git history, not just current files.

If a maintainer's GitHub token were stolen tonight, what would stop an attacker from pushing and executing a malicious workflow?

Your CI/CD pipeline is part of your attack surface. Test it like one.

#GitHubActions #SupplyChainSecurity #DevSecOps #OffensiveSecurity #FearsOff

[FearsOff Cybersecurity @FearsOff]

An AI-powered attacker reached root during the breach of DIVD.

That is important.

But the bigger lesson is what happened after the initial compromise.

On September 21, the Dutch Institute for Vulnerability Disclosure was breached through Zammad, an open-source helpdesk and ticketing platform.

During the investigation, DIVD identified two previously undisclosed vulnerabilities:

CVE-2026-102489 - a remotely exploitable vulnerability affecting Zammad 6.3.0 to 6.5.4 that can lead to code execution and session leakage.

CVE-2026-102490 - a local privilege-escalation vulnerability that allowed the Zammad user to escalate to root.

DIVD says the attacker used AI agents that selected their next actions dynamically during the intrusion.

And they moved fast.

According to DIVD, the agentic nature of the attack allowed parts of the intrusion to happen in seconds.

The attacker was not flawless either.

DIVD reported that the agent interfered with its own activity by performing password spraying and left unusually detailed comments explaining its actions, making parts of the intrusion easier to reconstruct.

That is what makes this incident interesting.

An AI-driven attacker does not need to be perfect.

It needs to move quickly enough to exploit the opportunities your environment gives it.

DIVD says network segmentation helped stop the attackers from moving deeper into its infrastructure.

That shifts the defensive question.

It is not only:

"Can this system be compromised?"

It is also:

"What happens if it is?"

If your helpdesk, ticketing platform, or another internet-facing internal service were compromised today, what could the attacker reach next?

What credentials could it access?

What internal systems trust it?

How far could it move before something stops it?

Prevention matters.

So does blast radius.

Assume the helpdesk is compromised.

Then check what it can touch.

Stay secure. Turn your FearsOff.

#CyberSecurity #AISecurity #ZeroDay #AgenticAI #IncidentResponse #NetworkSecurity #FearsOff

[FearsOff Cybersecurity @FearsOff]

When even ransomware crews get pwned, CISOs should pay attention.

ShinyHunters claimed it compromised Cl0p's dark web leak site through an unauthenticated file-upload flaw in Grav CMS, defaced the site, and then turned Cl0p's own extortion model against it.

The reported demand: eight figures.

But the money is not the most interesting part.

The real lesson is that sophisticated operators can still fail on basic security controls.

For CISOs, this should sound familiar:

* Internet-facing systems with unclear ownership
* Legacy CMS platforms that escape patching cycles
* Temporary infrastructure that quietly becomes permanent
* Upload functionality with weak validation
* Secrets, logs, and operational data exposed after a single foothold
* Third-party and peripheral systems sitting outside the "crown jewel" conversation

This is where attack surface management stops being a dashboard exercise.

The question is not only:

"Are our critical systems secure?"

It is:

"What can an attacker reach that we have forgotten about?"

Because attackers do not prioritize assets the way organizations do.

They look for the easiest path to leverage.

A forgotten admin panel can matter more than a hardened production server.

A poorly secured vendor portal can matter more than another million-dollar security platform.

A temporary upload endpoint can become the beginning of a major incident.

For security leaders, the takeaway is simple:

Know what is exposed.
Know who owns it.
Continuously validate it.
Test the paths attackers are most likely to use.

Cl0p spent years exploiting weaknesses in other organizations.

Now, allegedly, another threat actor treated Cl0p like any other victim.

Operational security has no exceptions.

Hack yourself before others do.

Stay secure. Turn your FearsOff.

#CISO #Cybersecurity #AttackSurfaceManagement #ExposureManagement #OffensiveSecurity #ThreatIntelligence #RedTeam #FearsOff

[FearsOff Cybersecurity @FearsOff]

Two bugs. 72 hours. Under $3,000 in tokens. A working path into an OpenAI employee's Codex session and the company's internal GitHub monorepo.

OpenAI paid $6,500 and noted that testing the forum was outside bounty scope. Out of scope is a program boundary. It is not a risk boundary.

Hacktron AI published the chain on 18 September. Responsible disclosure, not a production dump.

The chain

1. Entry. community[.]openai[.]com runs Discourse. HEIC/HEIF uploads skipped the usual FastImage check and were decoded through ImageMagick and libheif. A heap overflow (CVE-2026-32882) gave RCE on the forum host. Discourse published GHSA-vhm9-85gw-x335 on 28 July, CVSS 8.8, and shipped patched builds.

2. Escalation. Overly broad OpenAI Community sign-in tokens turned a compromised forum session into access to ChatGPT and Codex accounts for authenticated users, employees included. OpenAI narrowed those permissions and revoked affected tokens and sessions.

3. Blast radius. One employee Codex environment was connected to the internal openai/openai monorepo. The team opened a benign pull request as proof and says it did not review proprietary code. OpenAI states no sensitive user data was taken. Reachable connectors are not the same as exfiltrated data.

The detail most coverage buried: the exploit was written by models. Opus 4.8 could not get there. Opus 5 shipped on 24 July and produced a working ARM64 exploit in about three hours. No model jailbreak required to reach the model company.

Timeline. Research began 23 July. RCE at 05:00 UTC on 25 July. Bugcrowd report the same morning. OpenAI confirmed its identity-side fix at 22:49 UTC, roughly 14 hours later. Discourse had a fix by 27 July. Bounty paid 1 September.

The scope line matters because the forum was only hop one. The identity control is what made an employee Codex session, and a connected internal repo, reachable. Scope on a submission form does not redraw the architecture.

We see the same pattern at FearsOff on most serious chains. Researchers are asked to prove impact without touching production data. The proof then gets used to argue the issue was not that bad. Severity gets argued down to the first bug instead of the chain. Bounty math becomes the public scoreboard instead of the architecture lesson. The next researcher watches and thinks twice before reporting.

Patch fast, as OpenAI did on the identity side. Then describe the chain the way an attacker would, not the way a program FAQ does.

Two questions for your own stack: which dependency has nobody rechecked since the day it was added, and which identity token still trusts it?

#CyberSecurity #OffensiveSecurity #ResponsibleDisclosure #BugBounty #AppSec #FearsOff #AISecurity #AI

[FearsOff Cybersecurity @FearsOff]

A 9.9-severity flaw in ConnectWise ScreenConnect showed why remote access tools are architecturally fragile. The mechanism is worth breaking down because it reveals the real problem.

The attack chain:

Social engineering got a victim to run a rogue ScreenConnect client. Once inside, that client didn't need to compromise anything else. It found other active ScreenConnect sessions on the same network and pushed files to them "without authorization or host confirmation in certain circumstances" - per ConnectWise's advisory. Four VBScript files then propagated access across the organization's remote support footprint.

Why this matters beyond the CVE:

The flaw wasn't exotic. The rogue client exploited the fact that remote access tools are built on implicit trust. Once a legitimate client can see another session, the permission model expects the user to refuse unauthorized transfers. But when a modified client ignores that prompt, there's no secondary control.

This is systemic. Remote access tools grant broad privileges by design (file transfer, shell access, screen sharing) but defend them with behavioral controls - prompts, logging, UI barriers. Bypass the client, and the authorization layer collapses.

ConnectWise patched CVE-2026-84869 in version 26.6.5 on September 8. CISA flagged it for federal agencies with a three-day remediation deadline. But patching this one vulnerability doesn't solve the category risk.

The real question:

If remote support tools sit in your environment, assume one compromised client will reach others. Can your architecture survive that? Or does your network segmentation actually isolate remote access traffic?

[FearsOff Cybersecurity @FearsOff]

Revolut did not get breached in the classic sense. Someone used a real government-agency email domain, passed authentication, and Revolut handed over the files.

What left the building: passports and driving licences, KYC selfies, names, dates of birth, occupations, addresses, phone numbers, IBANs, account statements, withdrawal records, and full transaction histories - including Bitcoin. Revolut says a limited set of customers was affected, systems and funds were untouched, and high-net-worth users appear to have been the target.

Latest development (14 September): attackers have started publishing identity documents and selfies on Telegram - including material linked to named high-profile customers - and are threatening daily dumps until Revolut pays. Posts circulating this morning claim the ransom is 10,000 BTC. That figure has not been confirmed by Revolut or authorities. Even unconfirmed, the pattern is familiar: leak a few files, raise the price, keep the pressure on the people in the pack rather than only the company.

10,000 BTC is theatre as much as negotiation. Paying rarely stops a leak once documents are already out. Not paying leaves affected customers exposed to identity theft, targeted phishing, and on-chain doxxing. Either way, the customers did not get a vote.

The control failure is process, not the firewall:

▪ A valid government domain is not a valid request.

▪ Official data requests need a known-good channel, dual control, and out-of-band verification.

▪ Passport + selfie + IBAN + BTC history is a complete identity kit. It should never move on a single email thread.

If your platform stores KYC and crypto history, test the legal/compliance workflow the same way you test the app. Last week's "reasonable belief" is this week's ransom headline.

[FearsOff Cybersecurity @FearsOff]

The phishing email came from Trezor's legitimate domain.

That's what made this attack dangerous.

On September 9, Trezor warned users that its third-party email provider had been compromised and used to distribute a phishing email titled:

"Critical Security Alert: STM32 Entropy Vulnerability"

This wasn't a typical lookalike-domain attack.

Recipients reported that the email passed SPF, DKIM and DMARC authentication. Bitcoin security researcher Jameson Lopp noted that the messages did not appear to be spoofed.

Trezor has since identified the provider as Brevo and said an unauthorized actor used its Brevo account to send the campaign. Roughly 347,000 email addresses in Trezor's opt-in newsletter database were affected.

The lure was carefully chosen.

Attackers claimed that STM32 microcontrollers in Trezor devices were generating weak recovery phrases.

Weeks earlier, a real firmware bug affecting Coinkite's Coldcard had reduced seed entropy from 128 bits to as little as 40 bits. TRM Labs linked that vulnerability to approximately 1,816 BTC - about $116 million at the time - stolen from more than 5,200 addresses.

The phishing campaign took a real security fear and redirected it at another hardware-wallet community.

BitBox reported a similar campaign the same day and said multiple Bitcoin companies appeared to have been targeted through a shared newsletter provider.

And for Trezor, this follows another third-party incident.

In August, a breach at shipping provider ShipMonk exposed customer information. Trezor's updated investigation puts the total at 80,689 affected customers.

The lesson isn't simply "watch for phishing."

It's that attackers can inherit your organization's trust by compromising the systems around it.

A legitimate sender.
Authenticated email.
A believable security incident.
A trusted brand.

When those signals can no longer distinguish legitimate communication from an attack, the human becomes the last control.

If an attacker could send authenticated phishing emails from your company's real domain tomorrow, how quickly would your customers recognize the attack?

#CyberSecurity #Phishing #CryptoSecurity #SupplyChainRisk #InfoSec

[FearsOff Cybersecurity @FearsOff]

$320M moved. 3,400 BTC returned. ~$47M kept.

And an OP_RETURN declared:

"we are whitehats."

That sentence is doing a lot of work it did not earn.

The Liquid Network incident has triggered a debate bigger than one exploit: what does "white hat" actually mean?

Because white hat is not a label you give yourself after taking control of someone else's assets. It is a constraint on how you operate.

There is a legitimate problem underneath this debate.

Too many bug bounty programs lowball critical findings. "Thanks for the report" is not compensation. Artificial caps, severity games, ghosted researchers, and companies protecting nine figures of TVL while offering four-figure rewards create terrible incentives.

Researchers should push back.

Negotiate. Escalate. Walk away.

But a broken bounty market does not create authorization.

A white hat finds the hole, proves it with the minimum necessary PoC, reports it, then negotiates aggressively for what the work is worth.

Taking the reserve first and negotiating what you keep afterward is fundamentally different.

And stretching "white hat" to cover that behavior hurts the researchers who actually follow the rules.

The next CISO becomes more suspicious. The next legal team gets more defensive. The next researcher demonstrating impact gets treated less like the person who found the fire and more like the person holding the match.

We know the other path because we practice it.

Our team recently found a critical vulnerability in a major crypto project. We could have moved millions.

We didn't.

We demonstrated it with a $100 proof transaction, got it fixed, and negotiated the bounty afterward - including escalating when the initial offer did not reflect the severity.

That is the job.

Black-hat capability. White-hat discipline.

You can believe researchers are chronically underpaid and still reject "pay yourself from the protocol" as the solution.

Researchers: don't work for coupons. Negotiate. Escalate. Walk away.

Projects: pay criticals according to the damage they can cause, not the minimum you think a researcher will accept.

But protect the line.

White hat is not "I gave most of it back."

White hat is how you behaved before you had leverage.

#Cybersecurity #WhiteHat #BugBounty #Web3 #CryptoSecurity

[FearsOff Cybersecurity @FearsOff]

Your inbox doesn't lie: eight "reset your password" emails in three minutes, and you never touched the button.

Here's what we know as of September 4:

1. Confirmed: Thousands of X users, including CoinDesk staff and prominent crypto accounts, reported unsolicited password-reset emails, unfamiliar-login alerts, and temporary lockouts. Some received up to 10 reset emails within hours.

2. Confirmed: Many of the reset emails appear to be legitimate X-generated messages. X's recovery flow can be triggered with a public username, though the actual confirmation code still goes to the account's registered email or phone.

3. Confirmed: X Product Engineering's Mridul Singhai said the company has "so far" found no evidence of a breach. He suggested attackers may see greater value in compromised accounts now that X Money is more widely available.

4. Not confirmed: Researchers have pointed to several possible ingredients, including older Twitter/X data exposures, a credential-stuffing operation involving millions of accounts, and a separate phishing campaign impersonating X login alerts. None has been confirmed by X as the cause of this surge.

5. What to do: Enable Password Reset Protect under X's security settings and use strong 2FA, preferably an authenticator app.

The bigger lesson: attackers don't necessarily need a brand-new breach. Old exposed credentials, automated login attempts, and permissive recovery flows can remain useful long after the original data exposure.

Have you turned on Password Reset Protect yet?

[FearsOff Cybersecurity @FearsOff]

Your AI Login Doesn't Need a Password to Get Stolen.

Anthropic is warning Claude users that malware already on their computer - not a flaw in Claude - is hijacking active sessions.

MFA didn't fail here. It was never asked.

MYTH: If an account has strong authentication, an attacker needs your password to get in.

REALITY: Anthropic warned affected users in a notice reported on August 30 that infostealer malware - including Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, plus Atomic Stealer on a small number of Macs - was stealing already-authenticated Claude browser sessions from infected computers.

A stolen authenticated session can let an attacker bypass the normal login flow, including the password and MFA challenge, because they're reusing a session that has already been authenticated.

MYTH: Unusual account activity means the platform itself was breached.

REALITY: Anthropic was explicit: "We have no reason to believe that this malware is related to Claude, installed through Claude, or related to anything you did with Claude."

The infection was general-purpose malware arriving through unrelated activity. In one publicly shared case, the user reported downloading a pirated game. The malware happened to steal the victim's Claude session alongside other credentials and data on the infected machine.

MYTH: If your usage or billing looks normal today, you weren't affected.

REALITY: Anthropic told affected users that one warning sign was usage limits refilling and then quietly draining while they weren't using Claude.

The company signed out affected sessions, removed saved payment methods, and refunded charges identified as unauthorized. But signing out doesn't remove malware from the device. If the infostealer remains on the machine, a newly authenticated session can potentially be stolen again.

That's the bigger security lesson.

Session hijacking through commodity infostealers is a growing blind spot for cloud and AI accounts. Once an authenticated session is stolen, no phishing page or password guess is required to reuse it.

Does your org's incident response plan account for stolen session cookies - not just stolen passwords?

[FearsOff Cybersecurity @FearsOff]

The interesting part here isn't that ransomware operators are using AI. It's what they're using it for.

Two separate research teams, CloudSEK and Gambit Security, analyzed exposed infrastructure tied to a Russian-speaking group behind Aurora ransomware.

Both came to the same conclusion: the operators weren't just using Cursor to write code. They were using it during actual intrusions.

CloudSEK found an exposed open directory showing activity against more than 20 organizations in nine countries between April and July 2026. Four of those organizations later appeared on Aurora's leak site.

Gambit Security got even more specific.

It found the operator using Cursor Agent, running on Anthropic's Claude Sonnet model, during hands-on exploitation of 10 targets between April 8 and May 21. In these cases, the attacker already had credentials or some kind of initial access.

Sometimes the instructions to the agent were broad: "tell me what rights the user has."

Other times, the attacker told it exactly what to run, including NTLM relay attacks using Impacket and certificate attacks using Certipy.

And it didn't all work.

A lot of the commands failed on the first attempt and had to be adjusted. That's actually one of the more interesting details in the research. This wasn't a polished demo showing an AI agent flawlessly hacking its way through a network. It was messy, iterative, hands-on use during real operations.

Reuters named six affected organizations: Christeyns in Belgium, Teckentrup in Germany, Scotland's Helideck Certification Agency, Bayou Title in Louisiana, an Argentine pharmaceutical distributor, and an Italian manufacturer.

There's another case worth paying attention to as well.

ReliaQuest recently disclosed Gryxa, a toolkit built by a separate financially motivated actor. That actor reportedly told an AI coding agent the project was an "authorized internal deployment" and used it to help build credential-stealing malware.

Different actors. Different operations. Similar idea.

We're moving beyond attackers using AI to make phishing emails sound better or generate some malware code.

They're starting to use commercial AI agents as part of the actual intrusion workflow.

So a genuine question for security leaders: does your AI acceptable-use policy assume attackers are using these tools to write phishing emails, or does your threat model account for them sitting alongside the attacker during hands-on-keyboard exploitation?

[FearsOff Cybersecurity @FearsOff]

Six days into a cyberattack, Boston Scientific still doesn't have a timeline for full recovery.

Here's what the company has confirmed:

Aug 25: Boston Scientific detects a cybersecurity incident causing a network outage and global operational disruption.

Aug 26: An SEC filing confirms disruption to order processing and shipping. Shares fall about 4% that morning.

Aug 27-28: Boston Scientific says there is no known impact to implanted cardiac devices, including pacemakers, or to previously established remote monitoring.

But new remote-monitoring activations are disrupted. Newly implanted devices cannot currently be enrolled for remote monitoring, although clinicians can still interrogate devices in person.

Aug 29: The company says cloud systems are unaffected and unauthorized activity was limited to certain on-premise systems. Manufacturing, processing and shipping remain disrupted, with no timeline for full restoration.

So far, Boston Scientific has not publicly attributed the attack or disclosed whether data was accessed or stolen.

The important distinction: a cyberattack doesn't have to switch off a pacemaker to create potential patient-care risk.

The devices may still work. But what happens if the systems used to manufacture, deliver and remotely monitor them stay disrupted?

Six days in, that's the question worth watching.

[FearsOff Cybersecurity @FearsOff]

Five crypto projects lost an estimated $14.1M in six days. Three failed on the same question: who actually authorized this?

1️⃣ TERM LABS - AUG 23 - ~$8.5M

An address funded with 2 ETH from Tornado Cash took nearly all votes in four of five USDC vaults and ~91% of the ETH Meta Vault. The proposal passed a seven-day timelock in public view. About 2,843 ETH and 1.68M USDC left the vaults.

2️⃣ BOUNCEBIT - AUG 19-20 - ~$3M

A caller could name another account as the source of funds without proving authorization. 286.5M BB moved across 14 transactions. No private key or signature was compromised.

3️⃣ THE SANDBOX - AUG 21-22 - ~$675K

LayerZero delegate permissions were hijacked through approveAndCall on the SAND OFT on Base, ultimately draining 14.77M SAND from the Ethereum OFT Adapter.

4️⃣ ALLBRIDGE - AUG 19 - ~$191K

A malicious CCTP message received a valid Circle attestation without a corresponding legitimate settlement. The contract failed to adequately verify the sender, recipient, or settlement.

5️⃣ MAYA PROTOCOL - AUG 18 - ~$1.7M DIRECT

Six chained bugs created an uncapped subsidy. A 100 CACAO deposit claimed 99.93% of a pool after ~49M CACAO was incorrectly credited. CACAO fell 88.7%.

Three of these incidents point to the same failure mode:

Asserted authority substituted for verified authority.

BounceBit trusted the funder named by the caller. Allbridge trusted an attested message without establishing settlement. The Sandbox accepted a configuration change without establishing true authority.

Maya was different: a bounds failure. Term was almost the inverse: governance checks passed while the wrong party controlled the votes.

The question for security teams isn't just:

"Would our last audit have caught these?"

It's:

"Which of these was our audit designed to catch - and which failures were outside its scope?"

[FearsOff Cybersecurity @FearsOff]

CVE-2026-69836 required no credentials and no user interaction - and affected Microsoft Entra ID.

10.0 out of 10.

The maximum possible CVSS score.

And this one was in Microsoft Entra ID - the cloud identity platform behind authentication and access across Microsoft 365, Azure, Dynamics and thousands of connected applications. 🔓

Here's what Microsoft disclosed about CVE-2026-69836:

The vulnerability was a deserialization of untrusted data flaw in Entra ID.

In simple terms:

Untrusted network data → unsafe deserialization → remote code execution

The CVSS vector tells the rest of the story:

Network exploitable
Low attack complexity
No privileges required
No user interaction required
High impact to confidentiality, integrity and availability

In other words, an attacker did not need a compromised account or a victim clicking a link. Successful exploitation could allow an unauthorized attacker to execute code over the network.

That's an especially serious failure mode for an identity platform sitting at the center of access to Microsoft cloud environments.

Microsoft credited Principal Security Engineer Robert Fitzpatrick with discovering the vulnerability.

There's also an important update: Microsoft initially listed the vulnerability as exploited, but corrected that assessment on August 21 and said it had not been exploited in the wild.

The vulnerability affected Microsoft's hosted service, and Microsoft says it has already been fully mitigated. No customer patch or other remediation action is required.

And CVE-2026-69836 wasn't the only major Microsoft cloud vulnerability disclosed that week. CVSS 10.0 flaws were also published for Azure Arc, Exchange Online and Azure Managed Instance for Apache Cassandra.

The interesting incident-response question isn't just "Was it patched?"

It's this:

If a CVSS 10.0 vulnerability existed inside your identity provider for another 30 days, what evidence would you actually have to detect exploitation - and what could you do about it?

#CyberSecurity #MicrosoftEntra #EntraID #CVE #IdentitySecurity #CloudSecurity #IncidentResponse

[FearsOff Cybersecurity @FearsOff]

Watch what CISA just flagged as actively exploited: a vulnerability in MLflow, an AI and ML lifecycle platform, being abused to steal cloud credentials.

Pair that with the Rust supply chain attack that hit developer build pipelines this same week, and a pattern is hard to miss. The tools we adopted to move faster on AI are now first-class attack surface, and attackers found them before most security teams finished inventorying them.

MLflow, model registries, notebook servers, vector databases, and ML orchestration platforms tend to share three uncomfortable traits. They were deployed by data teams, not security teams. They sit close to cloud credentials and sensitive data. And they rarely appear in the asset inventory the SOC actually monitors.

That combination is exactly what an attacker wants: privileged, connected, and unwatched.

If you are standing up AI capability this year, the security work is not a future phase. The exploitation is already in the KEV catalog.

Three questions worth asking your team this week:
Do we know every ML and AI platform running in our environment?
What can each one reach if compromised?
Who is watching them?

What is sitting in your AI stack that has never been through a security review?

#AISecurity #MLSecurity #CloudSecurity #CISO #KEV

[FearsOff Cybersecurity @FearsOff]

Three Crypto Breaches. None Started With the Wallet.

250,000+ crypto customers had personal data exposed in the space of a few days. The private keys weren't the weak point. 🔍

Here's what happened:

➡️ August 13 - Trezor

Trezor disclosed a breach at ShipMonk, its fulfillment partner, affecting 13,689 customers.

11,742 had names, emails, phone numbers and shipping addresses exposed. Another 1,947 had names, cities and emails exposed.

Trezor's own systems and devices were not compromised.

➡️ August 16 - SafePal

SafePal disclosed an authorization flaw in its order-tracking plug-in that exposed order information belonging to approximately 39,798 customers.

The affected data included names, emails, shipping addresses, phone numbers and purchase details.

SafePal said seed phrases, private keys, wallet passwords and funds were not compromised.

➡️ August 17 - Bits of Gold

Bits of Gold reported that attackers accessed customer information through a third-party data analytics provider.

Approximately 200,000 customers were affected. The exposed information included names, national ID numbers, emails, phone numbers, IP addresses, bank account details and public wallet addresses.

The company said funds, private keys and passwords were not exposed.

Three incidents. Three different paths in.

Fulfillment.
Order tracking.
Data analytics.

The common denominator wasn't the cryptography.

It was sensitive customer data sitting in systems adjacent to the core product.

That's an important distinction for security teams.

You can harden the wallet, isolate private keys and audit the core application - while an order-tracking tool or analytics provider still holds enough information to make your customers valuable targets for phishing, impersonation and social engineering.

So the vendor-security question isn't only:

"Can this vendor access our production environment?"

It's also:

"What could an attacker do with the customer data this vendor can access?"

How are you auditing vendors that never touch your core product, but do touch your customers?

[FearsOff Cybersecurity @FearsOff]

North Korea used servers vulnerable to a bug we found as C2 in its latest campaign targeting the defence, aerospace, and aviation sectors.

Check Point's report last week: Lazarus exploited a Windows kernel zero-day, CVE-2026-68820 in afd.sys, since at least early July against defense, aerospace and aviation targets in France, Germany, Brazil and India.

The campaign ran two parallel infection chains. One used signed-binary DLL sideloading to execute MISTPEN in memory. The other used a trojanized PDF viewer to deploy a new backdoor, Troy. Both could escalate to SYSTEM through CVE-2026-68820, followed by a new FudModule build designed to disable EDR visibility. MISTPEN ultimately deployed ForestTiger for long-term access.

Microsoft patched the zero-day on 11 August.

Much of the C2 infrastructure wasn't theirs.

Check Point found compromised Roundcube, WordPress and PrestaShop servers being used as relay infrastructure. It assesses that Lazarus likely authenticated to vulnerable Roundcube servers using leaked credentials, exploited CVE-2025-49113, and planted RelayShell.

The researchers identified at least 17 likely relay nodes.

One compromised organization headquartered in France was then used to spear-phish targets worldwide - borrowing a legitimate organization's infrastructure and reputation to make the messages more credible.

CVE-2025-49113 is ours.

Our co-founder @k_firsov discovered and reported it in May 2025: authenticated RCE via PHP object deserialization, CVSS 9.9, sitting in the Roundcube codebase for more than a decade.

Roundcube patched it on 1 June 2025.

Attackers diffed and weaponized the vulnerability within 48 hours of the patch becoming available, with a working exploit offered for sale days later. We published the full technical breakdown to give defenders parity.

CISA added CVE-2025-49113 to its Known Exploited Vulnerabilities catalog in February 2026, with a 13 March remediation deadline for covered US federal agencies.

And Lazarus was still exploiting unpatched Roundcube servers in this campaign.

We know the tradecraft because we spend our year on the other end of it.

Lazarus is heavily involved in cryptocurrency theft, and we run continuous adversarial simulation against exchanges and protocols that sit high on the DPRK targeting list.

The objectives differ, but the tradecraft overlaps: recruitment lures, signed-binary sideloading, credential theft, and kernel-level evasion.

Theft there. Espionage here.

If you build aircraft, satellites, drones, avionics, sensors or related defense technology, your engineers fit the targeting profile.

And your internet-facing Roundcube, WordPress or PrestaShop infrastructure can become someone else's C2 if it isn't secured and patched.

We find the bugs that might end up in campaigns like this one.

We also run the campaign against our own clients first, on purpose, with a scope document.

Our research: https://t.co/rsli4kOI9i