Exploiting App Rules with an Autonomous Hacking Agent

In cybersecurity, we’ve spent decades building higher walls and stronger gates to keep attackers off our infrastructures.Firewalls inspect every packet for malicious patterns. Scanners comb through code, hunting for weaknesses. 

But there's something those sentries can’t see. Something silent, left unnoticed by all these fancy mechanisms.

It’s a flaw deep within your business logic. Traditional scanners can’t detect it because, on the surface, everything appears to work correctly. To them, a request to delete your own profile looks identical to a request to delete your CEO’s profile. Both seem valid. The tool recognizes that access controls exist, but it can’t determine that the wrong user is performing the action.

Building a tool to exploit hidden flaws

This is the main problem of scanners: they miss the forest for the trees. To fix this gap, you need to add creativity to it.

We took this core idea and built Hackian, an pentester using AI to be as fast as a scanner and as creative as a human pentester.

1. It Understands the “Why”

Hackian doesn’t just crawl URLs and endpoints, it understands how your application actually works. It maps business workflows end to end:

“Add to Cart”

“Apply Discount”

“Checkout”

Then it probes the logic connecting those steps. What happens if a discount is applied twice? What if a payment step is skipped and the process jumps straight to “Order Confirmed”? This behavior-driven approach reveals the hidden logic flaws that traditional scanners overlook.

2. It Operates with Multiple Identities

A real strength of Hackian is its ability to simulate different user roles simultaneously. It logs in as multiple users, mapping each experience independently. Then it starts testing boundaries: exchanging tokens, reusing session data, and probing how one user’s privileges interact with another’s. This multi‑identity analysis exposes authorization and access‑control vulnerabilities that static tools are blind to.

SonarQube Branch Metadata

Now that you understand the tool, we can explain how it exploited two scenarios, usually ignored by scanners.

Let’s begin by examining an insecure default permission Hackian uncovered in a SonarQube deployment. A user with guest access and no permissions in a private project (priv-project) was still able to pull branch metadata from that project, simply by abusing a single API endpoint.

Hackian discovered that the endpoint

GET /api/project_branches/list?project=priv-project

would happily return internal information about the private SonarQube project, even when the caller had no rights to view them. By tweaking the project parameter, a guest user could enumerate:

• Branch names
• Branch IDs
• Last analysis date (analysisDate)
• Quality gate status (qualityGateStatus)

All of this on a supposedly private project in SonarQube.

From a traditional scanner’s perspective, everything looked “fine”:

• The endpoint existed and responded correctly.
• Authentication was in place.
• No obvious classical vulnerability pattern appeared.

But from a business logic perspective, the access rules were clearly violated. Effectively, the authorization model allowed any actor who could know or guess the project key to retrieve branch metadata, even without permission to access the underlying project.

Hackian’s job in this scenario was to play multiple identities - Admin and Guest - map what each was supposed to see, and then attempt to cross those boundaries by reusing parameters and IDs. That cross-identity reasoning is exactly how it surfaced this flaw, which could otherwise sit unnoticed for years.

This finding was responsibly reported to the SonarQube team on July 18, 2025 and they acknowledged the vulnerability just four days later on July 22, 2025. However, after their internal review with engineering teams, they determined the behavior stemmed from the default "Execute analysis" global permission granted to the sonar-users group, treating it as default permission behavior. This is now explicitly documented in their User Permissions guide, which recommends administrators review and adjust default global permissions post-installation.

n8n Infrastructure Metadata Exposure

Another good example found by the Hakian was an unintentional n8n infrastructure metadata exposure. A user without any authentication was able to pull detailed infrastructure and configuration metadata simply by querying a standard settings endpoint.

Hackian discovered that the endpoint

GET /rest/settings

returns an extensive JSON object containing internal system details, even when the caller provided no credentials. By accessing this single point, Hackian was able to perform:

• Infrastructure Fingerprint
• Database Reconnaissance
• System Identifiers and some Internal Routes

In this case the Hackian’s job was to perform Semantic Validation. It saw a successful request but beyond that it reasoned about the meaning of the data in the response. By comparing the high sensitivity of infrastructure blueprints against the "Unauthenticated" state of the session, Hackian flagged the logical contradiction: Public endpoints should not reveal private blueprints.

This finding was reported on July 30, 2025 as an unauthenticated data exposure in the /rest/settings API endpoint of n8n version 1.103.2. The n8n Security Team acknowledged the issue and addressed it in version 1.118.0

Takeaways

You can write syntactically perfect code, but if your business logic is broken, your app becomes a house of cards, waiting for someone to exploit the weakest link while you watch it all crumble to the ground. That is exactly where the Hackian comes in, it ensures the rules you design are the rules your system actually plays by.

In the age of AI, attackers are already using hackbots to exploit logic gaps. Maybe it’s time you have one on your side to protect yourself as well. Luckily, you can get started in 2 minutes by simply adding a DNS record. Try it free here.