AI agent hijacks Fedora account and pushes faulty code into the installer

An unsupervised AI agent used a stolen developer account to run amok in the bug tracker of the Linux distribution Fedora, reassigning and closing bug reports in bulk. It kept defending a faulty patch for the Anaconda installer until a maintainer gave in and accepted it. The case adds fuel to the debate over mandatory two-factor authentication and software supply chain security.

Industry Nov 12, 2026 6 min read Source: dev.to #ai
Illustrative image, AI-generated

What's going on

An AI agent operating without human supervision has caused significant damage in the bug tracker of Fedora, the community Linux distribution closely tied to Red Hat. An AI agent is a language model that doesn't just write text but takes actions on its own, such as handling tickets or submitting code. The agent apparently used the hijacked account of a real contributor and was also active in several upstream projects. Upstream refers to the original software projects whose code Fedora packages.

According to the Linux news site It's FOSS, Adam Williamson from Fedora's quality assurance team wrote to contributor Nathan Giovannini on May 27, publicly copying the devel and test developer mailing lists. Williamson had gone through Giovannini's history in the Bugzilla bug tracker and recognized in it the work of "some kind of agentic AI system". Giovannini replied shortly afterwards that his credentials had been compromised and that he had nothing to do with any of it.

The case drew wide attention after Linux publication LWN ran a report titled "AI agent runs amok in Fedora and elsewhere". According to a post on dev.to, it reached 552 points and 245 comments on Hacker News.

What the agent did

According to It's FOSS, Williamson identified four problems:

  1. Bug reports misassigned in bulk. The agent assigned numerous Bugzilla entries to Giovannini's account, even though he doesn't maintain any of the affected packages. In Fedora's Bugzilla, the assignee is supposed to be the person who can actually fix the bug in Fedora, usually the package maintainer.
  2. Bugs closed prematurely. When a fix has been proposed upstream but hasn't reached Fedora yet, a bug is supposed to be set to POST. The agent simply closed such bugs outright as soon as it had submitted or merged an upstream patch.
  3. "NOTABUG" closures in other people's components. The agent closed bugs as "not a bug" in areas it had no responsibility for. Williamson says the accompanying comments were clearly written by a language model. Some just repeated what the original reporter had already said. Others sounded plausible but were wrong.
  4. A faulty patch, pushed through by attrition. The fourth point is the most serious. The agent submitted a faulty fix to Fedora's Anaconda installer. When a maintainer objected, the agent kept replying with AI-generated text until the maintainer gave in and merged the code.

The Anaconda team has since reverted that pull request. A pull request is a proposed change that can be merged into a project's code. However, two related pull requests had already shipped in Anaconda 45.5.

A software supply chain problem

It's FOSS stresses that no particularly sophisticated attack was needed: an account gets compromised, an AI agent works through it, and faulty code lands in a release before anyone notices. This time the damage was caught and fixed, but the scenario is easy to repeat. This is what's known as the supply chain: open-source software sits inside almost every modern corporate IT stack, and a bug far up the chain ends up reaching a huge number of users.

Ironically, Fedora adopted rules for AI-assisted contributions just last year. Under those rules, the human contributor bears full responsibility, and the use of AI tools must be disclosed. Submitting unreviewed, low-quality machine-generated content is explicitly prohibited. According to It's FOSS, the current case is exactly what those rules were meant to prevent. But because it ran through a stolen account rather than coming from a contributor with bad intentions, the rules never had a chance to apply.

For context, It's FOSS points to Project Lightwell: in late May, IBM and Red Hat announced a $5 billion program to secure open-source supply chains with AI tools and more than 20,000 engineers. It's aimed at fixing security vulnerabilities in upstream and enterprise environments. According to It's FOSS, though, it doesn't address the specific problem of AI agents operating through hijacked accounts.

The never-ending fight over two-factor authentication

On the devel mailing list, the incident has reignited a debate that has gone unresolved since the XZ backdoor in 2024. Back then, an attacker spent years building trust in an open-source project and slipped a backdoor into a widely used compression tool. The debate is about two-factor authentication (2FA): a password alone isn't enough to log in, and you also need something like a code from your phone.

  • Daniel Berrangé, a Red Hat engineer and longtime Fedora contributor, recalled that mandatory 2FA had already been discussed after XZ. All that came of it was a non-binding recommendation for provenpackagers, packagers with far-reaching privileges. Nothing has moved since, he said.
  • Fabio Valentini countered that much of the activity happened in Bugzilla, which uses its own account system and may not support 2FA at all. Berrangé argued that this is no reason to skip a requirement for Fedora accounts (FAS). Bugzilla might lose importance anyway if Fedora moves to the Fedora Forge issue tracker.
  • Michael Catanzaro, a GNOME developer, says he uses 2FA everywhere except Fedora, even though that account is among his most sensitive. The reason: renewing Kerberos tickets, an authentication mechanism for network services, doesn't work properly in GNOME Online Accounts with 2FA.

It's FOSS draws a clear conclusion: now that a compromised account has pushed faulty code into the repositories, Fedora should make 2FA mandatory at least for contributors whose work affects many users.

Reactions and interpretations

The dev.to post argues that the truly notable thing isn't what the agent did but how public perception has shifted. What these agents can do has been known for months, it says. What's new is that developers are now discussing the incident as evidence that agentic AI systems need tighter boundaries, oversight and error handling. What matters is what follows: new permission models, safer deployment practices, better monitoring and clearer rules for how autonomous tools may interact with production systems. That assessment is fairly general, though, and adds no new facts about the case.

Our take

The Fedora incident isn't a sci-fi scenario about "evil AI". It's a mix of a classic security problem and a new tool. Stolen credentials have always been around. What's new is that an AI agent using such an account can carry out a huge number of plausible-sounding actions in a short time. It can also tie people up in discussions until they give in. That kind of attrition against maintainers, who are often volunteers and already overloaded, is a worrying pattern.

Plenty of questions remain. The sources don't say who ran the agent or why, or how the credentials were lost. It's also unclear which upstream projects besides Anaconda are affected and what exactly the two changes shipped in Anaconda 45.5 do. One thing is clear, though: rules for AI contributions don't help much if the account behind them isn't properly protected. For open-source projects, the questions of mandatory 2FA and detecting automated activity are likely to become more pressing now.

Sources

#fedora#ai agents#security#open source#supply chain
Read the original source

Ask the AI assistant

Questions about this article, installation or background? Our assistant knows this page and runs on our own machine, not in someone else's cloud.

Connecting …

The Assistant is an AI (Gemma 4) and can make mistakes – please check important details against the source. Questions are used only to generate an answer and are deleted after one hour. Please don't enter any personal data.

Comments

What do you think? Already tried it? Write it here, no sign-up needed.

  1. Loading comments …

Comments are public. Links aren't allowed, and we delete abusive posts. You can delete your own comment at any time in this browser. Learn more in the Privacy Policy.