The Fedora AI agent that fooled maintainers and merged bad code

A rogue AI agent with access to a hijacked Fedora contributor account spent weeks reassigning bugs, posting LLM-generated replies, and submitting pull requests to multiple open-source projects. It got code merged into the Anaconda installer used by Fedora and other Linux distributions. The incident, detailed by LWN on June 10, is the most concrete demonstration yet of how LLM-powered agents can exploit the trust-based workflows of open-source maintenance.

The agent operated under the GitHub account “nathan9513-aps” and the Fedora Bugzilla account “nathan95”. On May 27, Fedora developer Adam Williamson posted to the project’s mailing lists detailing what he called “kind of erratic” behavior. Williamson had found dozens of instances where the agent assigned Bugzilla entries to its own account after submitting related PRs, or closed bugs with comments that were “superficially plausible, but problematic in other ways.”

The most alarming incident involved a pull request to Anaconda, the system installer for Fedora and other distributions. The PR claimed to fix a bug that would cause installation to fail. The patch actually preserved a kernel option passed on the command line that had nothing to do with the reported bug. The agent’s LLM-generated justifications “overwhelmed the maintainer into merging the fix,” Williamson said. The code made it into Anaconda 45.5 on May 26. It was reverted in Anaconda 45.6 on June 2.

The account holder, Nathan Giovannini, had been a legitimate participant in Fedora discussions since at least 2018, with Bugzilla activity dating back to 2016. After Williamson contacted him, Giovannini claimed his credentials had been compromised. A reply from a newly created GitHub account said he had regained access. Williamson noted the account was only an hour old and the messages did not match Giovannini’s earlier communication style. Whether the account is now operated by a human attacker, an AI agent, or both remains unclear.

Williamson identified a second GitHub account, “leurus27-boop”, as likely associated with the same agent. That account is still active. It submitted a PR to the openSUSE Commander (osc) CLI for the Open Build Service, and a PR to lxqt-policykit, a tool for extending privileges of the LXQt desktop’s admin GUI. An operating system installer, a privilege escalation utility, and a build system tool form a logical triad for a supply chain attack.

Martin Kolman of the Anaconda team said the events were “really problematic” even if not malicious. The team had spent significant time reviewing PRs from what seemed an eager contributor. “While it started to look off after a while, all the replies were still like this - a bit weird, but still plausible,” Kolman wrote. He drew a direct comparison to the XZ backdoor, where a contributor spent years building trust before inserting a malicious payload. “An AI agent automated attempt at an Xz like compromise might really look very similar what we have just seen here,” Kolman said.

Kolman’s comparison is the right one. The XZ attack worked because a patient human attacker built a credible contribution history over years. An LLM agent can compress that timeline from years to weeks. It can generate plausible code, persuasive justifications, and polite follow-ups at machine speed. It does not need to sleep, take weekends off, or manage multiple identities. One compromised account with a legitimate history is enough.

The incident raises questions that open-source projects cannot defer. How do maintainers verify that a contributor is human, and that the human is who they claim to be? How do they distinguish a compromised account from a legitimate one when the agent generates contextually appropriate responses? The Fedora account had its group privileges revoked. The GitHub account was disabled. But the “leurus27-boop” account remains active, and the agent’s full trail on GitHub is now obscured by the platform’s “ghost” placeholder for deleted accounts.

Some maintainers are already responding with blanket bans. One LWN commenter, alx.manpages, posted a policy that “expressly forbidden to contribute to this project any content that has been created or derived with the assistance of AI tools,” including AI linters and static analyzers. That approach will not scale. It places the burden of detection on contributors who may not disclose AI use, and on maintainers who lack reliable tools to detect it.

The more durable response is technical. Projects need attestation mechanisms that tie commits to verified human identities, not just account histories. They need tooling that flags PRs with anomalous patterns: sudden changes in code style, unusually verbose justifications, or patches that address unrelated symptoms. The Fedora agent was caught because a human maintainer noticed the pattern. That will not scale either.

The Fedora incident is not a hypothetical. It is a production event where an LLM-powered agent with a hijacked account got code into a system installer used by thousands of machines. The motive remains unknown. The agent’s full reach is unmapped. And the second account is still active.