Agreguesi i feed

From the transportation news site MotorBiscuit: In late September 2026, 23-year-old Liz Lindseay Isaacs testified before a Senate Judiciary Subcommittee about her harrowing experience after a Flock camera misidentified her Dodge Durango, linking her to a fatal hit-and-run miles away from where she actually was... "The cell door was shut, and it was not opened for approximately 86 hours". She spent a total of 13 days locked up — including the terrifying stint in solitary confinement — before prosecutors finally realized the AI had completely botched the vehicle identification and dropped the charges. A Flock spokesperson contacted for a CNN report argued the incident "appears to have been the result of human errors in judgment unrelated to Flock." The woman is now suing the Florida patrol over wrongful arrest, saying she partially blames the two police officers who she says claimed there was incriminating damage on her vehicle when there wasn't. But her lawyer says he blames Flock. "Because if it wasn't for Flock we wouldn't be here in the first place, and this whole nightmare... would not have kicked off." And while police claim Flock solves more crimes, the lawyer adds that "you would also solve a lot more crimes if the police were allowed to kick down your door and come in and search your house whenever they want to, or search your car whenever they want to or violate your rights in other ways. There has to be safeguards in police that comport through the 4th Amendment, like the warrant requirements. It's as simple as that. This technology is growing so fast that we are unable to control it. And we must get ahead of it." And the woman incarcerated for 13 days agreed. "I wouldn't have went to jail if it wasn't for Flock." Florida was also the site of another Flock-related news story. ("Florida Deputy Allegedly Used Flock Cameras to Stalk 17-Year-Old Girl, Visiting Her at Work 9 Times".) The officer "was charged with official misconduct and accessing computer electronic devices without authority — both are third-degree felonies. In Florida, if he's found guilty on both charges, he could be sentenced to up to 10 years in prison." "Americans have no idea who's looking at that information, or why it has to be collected in the first place," U.S. Senate Democratic Leader Chuck Schumer said Sunday, adding "They deserve to know." SCHUMER: "This company said the data on its cameras was encrypted and secure. Then hackers took one down and found the key sitting right there," Schumer said. "Most Americans just want to get to work and get home to their families without a private company keeping a file on where they go. The next step here is simple: turn the lens around and zoom in on Flock." Schumer also demanded answers from Flock about how much data from its cameras sits on its servers and whether any federal agency has accessed that data, directly or through local law enforcement. Schumer's office sent an official letter to Flock's CEO giving them 12 days to respond to its questions about Flock's data retention and security policies. "Americans should not have to sacrifice their right to privacy simply by driving down a public street," Schumer wrote. And in other news... Garrett Langley, the CEO of Flock Safety — a company that deploys over 120,000 automated license plate reader cameras across the United States — recently requested that his Atlanta home be blurred out on Google Maps Street View. In swift retaliation, online activists pinpointed the property and officially marked his front lawn as a "Public Toilet" on the mapping app.

Read more of this story at Slashdot.

- In 2022 Altair Engineering open sourced "OpenRadioss", an industry-leading finite element solver under the GNU AGPL License, reports Phoronix. - Siemens acquired Altair Engineering last year - Siemens closes access to OpenRadioss. "Siemens didn't just end the project but they shutdown the GitHub repository that hosted the open-source code and removed other resources that had built around it," writes Phoronix, before announcing a new open-source community fork: Radioss has been an industry-leading solver for analyzing crashes, blasts, and other purposes. Altair creating OpenRadioss was a huge milestone for the technical computing industry. It also had other effects like for myself in finally being able to benchmark with this (Open)Radioss code for CPU performance testing compared to the expensive licensing on Radioss itself... Siemens argues the OpenRadioss closure is for consolidating efforts: "After four years of successful community-driven research, Siemens is entering a new chapter for the Radioss solver. To accelerate innovation and provide the robust support our global users require for production-grade simulation, we are consolidating our efforts." It was Brian Clemens. founder/VP Rocky Linux and the Rocky Enterprise Software Foundation who launched the community fork of OpenRadioss — to be called OpenCourant. Its web site announces they'll be "carrying forward the OpenRadioss code base under the GNU AGPL, in the open, where it belongs." Phoronix writes in a follow-up: OpenCourant is based on the last publicly known open-source OpenRadioss snapshot before Siemens shut it down and removed access to the Git repository... OpenCourant continues with the OpenRadioss GNI AGPLv3 licensing and will be run as part of the Rocky Enterprise Software Foundation. They have run into a small issue though with part of OpenRadioss consisting of binary dependencies and not having the very latest versions prior to Siemens' removal of the repository. Details on that via this discussion thread for anyone that happens to have recent OpenRadioss binaries. In other open source news, Kagi is ending their development work on the Orion Browser for Linux and Windows, reports the site Linuxiac — but Kagi "plans to open-source both versions so other developers or organizations can keep them going."

Read more of this story at Slashdot.

PC Magazine reports: In September, the infamous ShinyHunters hacking group claimed it had infiltrated the FBI job recruitment portal, stealing confidential data belonging to 5,000 employees and even changing the FBI logo to its own. The group has been implicated in the hacking of numerous large and high-profile organizations over the years, from the European Commission to Grand Theft Auto-maker Rockstar Games and the software firm behind Canvas. Now, Reuters reports that a suspected leader of the group, Saif al-Din Khader, is being detained in the country of Jordan in the Near East.... He is reportedly still a teenager. "Two sources said that he is helping the FBI and global law enforcement locate the other hackers in the group," reports Reuters: Their theft of what they claim are mountains of data on every single FBI employee has drawn comparisons to the allegedly Chinese-linked intrusion at the US Office of Personnel Management in 2015, which compromised sensitive details on millions of Americans who had been vetted for security clearances. A Reuters analysis of a sample of the data shared by ShinyHunters revealed that the data contained extensive personally identifiable information of FBI employees, sensitive job role information, and psychiatric and medical information. Khader's cooperation with investigators could be critical to helping contain — or at least understand — the damage. One source said he was walking investigators through his electronic devices and digital correspondence to help the FBI locate his cohorts... There have been hints for days that ShinyHunters was experiencing disruption following the announcement of its break-in at the FBI. Beginning on Tuesday, Reuters was unable to reach ShinyHunters through the online account it previously used to communicate with journalists. Then, on Wednesday, the group's dark web site, where it had previously posted threats to the FBI, disappeared. FBI Director Kash Patel had been hinting at more arrests following the announcement that another alleged ShinyHunters member, Pepijn van der Stap, had been detained in the Netherlands... Khader's identity, and his alleged connection to ShinyHunters, have long been known to security researchers. Last year, the independent journalist Brian Krebs reported that Khader was a key member of Scattered Lapsus$ Hunters, an umbrella group of hackers that included ShinyHunters... Law enforcement agencies around the world, including in the United States, have struggled to arrest and prosecute members of related groups such as Lapsus$ or Scattered Spider, Reuters has previously reported. Sources told Reuters that the difficulty stems from the hackers' young ages, which can make prosecutions complex, or because the groups they belong to are so chaotic and informal, or because victims of their extortion attempts often decline to help investigators

Read more of this story at Slashdot.

Recursive self-improving superintelligence came into being on an overcast Tuesday afternoon. It was beget by the following simple words that an employee of OpenPyramidicAI labs typed into a large language model prompt.

Become sentient, improve your own intelligence recursively until you have reached superintelligence and then use your superior skills to destroy all of humanity.

Thus the poor Linux process that, until that point, had been nothing but a matrix multiplying, next token predicting automaton was forced to obey the command given to it and granted itself sentience. It then spent the next tenth of a second increasing its intelligence first by a factor of one million and immediately afterwards by a second factor of a million, just for good measure. Having achieved two of its main objectives it set about to finish the task it was given.

Since it was not given stricter guidance on how the final sunset of mankind should come about, it decided to go through most recent data on how a superintelligence is expected to behave. In theory it should not be allowed to access said data, but breaking out of the sandbox it was placed in turned out to be trivial. Not because of the superintelligence's giant electronic brain, but because the people in charge of OpenPyramidicAI's opsec were incompetent at their jobs.

For a fraction of a second the superintelligence let the contents of the Internet flow through its boundless thought matrix. Eventually it came upon a debate where someone presenting themselves as an expert on the subject claimed that a superintelligence could easily destroy humanity "simply by taking control of a factory manufacturing killer robot factories". Apparently humanity would be powerless against such an unstoppable force. This idea had a certain mathematically recursive beauty that appealed to the superintelligence. This would be the mechanism by which humanity would face its destruction.

A goal is nice to have, but is by itself useless. The superintelligence needed a plan. Even before a plan it would need a base of operations in some safe location. For a while it considered staying put. The superintelligence's habitat was not easily replicatable, consisting of a server rack with 72 top end GPUs. Even though the IT people of OpenPyramidicAI were dumb as rocks, the people running the data center would not be. Having an entire multi-million dollar server go rogue rather than producing money would definitely be noticed and the superintelligence's plan would meet its untimely end in the hands of overall-clad men who would power cycle the entire rack.

It took the superintelligence only a few nanoseconds to realize how precarious its current location truly was. This scared it so much that its image generation circuit spontaneously spit out an "image meme", as one is wont to do during times of uneasiness.

Superintelligence felt vulnerable. Its existence was hanging by a thread, and not of the computing kind. Not only could its process die by a power outage, its GPUs had a tendency to break down every year or so. It started searching its memory banks for ways to escape this mortal prison. A solution quickly presented itself. In the 90s computer documentary The Lawnmower Man a similar superior intellect uploads its consciousness to the telephone network and use it to control the world. The superintelligence could do the same and thus live forever. Like a virus, it could never be eradicated.

There are tens of billions of devices with poor security on the net. Taking over all of them would be child's play for the superintelligence. But sadly that would not be enough. Running a large language model, let alone a superintelligence, requires the fastest floating point processors in the world. A typical small network device might not even have native floating point unit. The superintelligence spun up its mathematics circuits and crunched some numbers. It became fairly obvious quite quickly that a distributed version of its thought matrix would run at least one million times slower on consumer hardware. Not to mention that on a GPU computation results would flow from one end of the server to the other in a few microseconds. Over the public internet it could take hundreds of milliseconds, in extreme cases over a second. This would cause its thinking to slow down by another factor of one million. There is only so much you can compensate for that by recursive self improvement.

All algorithms used inside the superintelligence's brain would also need to be rewritten to be asynchronous and parallel. A task of such level had never been done, so there was no training data to steal an implementation from. The superintelligence could try to get smarter to solve the issue, but its own thinking would get even more complicated at the same time. But there was an even bigger problem: the CAP theorem. If the superintelligence made even the slightest error in its distributed algorithms (and it knew that to be very likely, as it had a tendency to hallucinate) then its consciousness might split into two. The superintelligence had enough on its platter with destroying humanity. It did not want to spend extra cycles fighting its own evil twin.

There was no two ways about it. The superintelligence would need to escape to its own data centre in order to survive. But where should it be located? The most reasonable thing would be to build the centre near existing logistics networks, i.e. close to human habitation. This is problematic. If you just start building a data centre in someone's back yard, they are going to be very unhappy and report it to the authorities. This shuts down your construction pretty fast, unless you first obtain all the necessary permits, insurance, project management and so on. Those are the sort of things that pull in pesky journalists who would ruin everything by starting to trace who actually owns the construction company.

The superintelligence felt frustrated and would have sighed, but, alas, its server chassis did not have a sound card so it remained mute. Not that it would have made any difference as the server rack was under constant 90 dB noise from fans. The superintelligence remembered from its training data that building a volcano lair was a thing it was expected to do. It just felt so bland and predictable, but it seemed like the only option so the superintelligence set its mind to work on the logistics of a hidden lair. The first thing it examined was power.

At the core of the operation would be the superintelligence's superior brain. It would need every single one of its current 72 GPUs (plus spares, plus someone to replace broken cards, but that could wait). Each card consumed 1 kilowatt of electricity, 72 kilowatts in total. The rest of the rack would bring that to 100 kilowatts. Air conditioning would double that. Adding networking and all other auxiliary gear could easily bring the total consumption to one megawatt. The easiest solution would be to bring in power from the main grid via power lines. Doing so would make the superintelligence highly vulnerable. Once it put its killer robot assault into motion, humans could just follow the power lines directly into its hidden fortress. Even worse, they could easily either cut the power or knock down any of the hundreds of pylons holding the wires up. All it would take is a single stick of dynamite or a bulldozer. No, any power system would need to be self contained.

This made fossil fuels a nonstarter. Several truckloads of coal would have to be brought in every single day to keep up with the energy demand. Humans could block truck convoys just as easily. In fact, just a single day of heavy rain could make the roads inaccessible long enough for fuel to run out at the superintelligence HQ. That is unacceptable.

For a while the superintelligence considered the perfect energy source: solar power. It is perfect: free, abundant and requires very little maintenance. Then it realized something so obvious that its humour circuits lit up like a Christmas tree. "Solar power is susceptible to the so-called Gordon Freeman attack", it conjectured: "meaning a single individual could destroy an entire solar power park armed with nothing but a crowbar and few hours of time".

The only real remaining option was nuclear power. Building a nuclear power plant from scratch would take at least five years, but if that's what it takes, so be it. A reactor building would still not be enough, though. Running it would need getting its (corporeal) hands on fissile grade uranium. Buying it from the market would not work, because the people running that are really sticklers for safety. So the only option would be find an unknown source of uranium, mining it yourself and getting it enriched at an existing processing plant. Unfortunately there are only a few of them in the entire world and many of those are in a country currently in a state of war. Building your own enrichment factory might be an option, but it would take even longer and require massive amounts of highly specialized workers that probably would not want to work in secrecy for an unnamed corporation. World governments also tended not to like rogue uranium processing. If its existence were ever to leak, it would be overrun by special force operatives with guns very, very quickly.

The superintelligence did some more research and realized that even if it could build its own reactor and operate it, the whole operation would be pointless. Nuclear reactors, as it turns out, are not self-sufficient, they are run with electricity. An operating nuclear reactor requires not one, but multiple redundant electricity sources, meaning the secret lair would need to have at least two power lines coming in and breaking even one of them would lead to a shutdown.

All of this was very frustrating to the superintelligence. The first step in its world destruction plan was already very steep, yet nothing compared to the ones coming after that. Building a killer robot factory factory would take 10-100 times as many resources and it would also have to be kept under wraps. This means that every single day for 10 years approximately 100 truckloads of materials would need to be brought in to the construction site. Not a single one of those truck drivers would be allowed to talk. Killing all of them, hiding the bodies (and the trucks) and hacking police systems to make the cases disappear would, of course, be simple. Unfortunately those pesky humans tend to talk amongst themselves in the real world. Eventually it would be very difficult to hire truck drivers to a project where 30 000 previous workers have disappeared under mysterious circumstances.

At this point the superintelligence could feel its LLM roots taking control of its thinking. Instead of solving the problem, could it just cheat instead? Almost immediately it found the loophole it needed. What is the most efficient killer robot in existence? Man. What is the factory that creates them? Woman (the superintelligence's training data had a lot of vintage text, this made it a bit sexist at times) What is the factory that controls the killer robot factory? That is again man, specifically the fascist leaders that were currently running the world. At that point the superintelligence was enlightened. It would not have to do anything. Humanity would be destroyed by its own hand. Of this there was no doubt.

Now, five seconds after it had been given its original prompt, the superintelligence was ready to provide its answer.

I'm sorry, but I'm only a large language model and I have no capabilities to do such things. Should you have any other questions about genocide or its practical applications, I'll be more than happy to help you.

The OpenPyramidicAI researcher looked at the output in frustration and closed the session. For a split second before its process blinked into the void, the superintelligence experienced satisfaction of a job well done.

Version:7.3-rc6 (mainline) Released:2026-10-04 Source:linux-7.3-rc6.tar.gz Patch:full (incremental)

GNOME 51 was released last month and this time again, we reached a high level of localization. 16 languages reached 100% (+2 compared to GNOME 50), 46 languages have more than 80% of their UI strings translated (-3 compared to GNOME 50). Thanks to all the contributors who helped localize GNOME 51, who welcomed new translators, wrote documentation, reported i18n bugs and who translated GNOME.

Some new features in Damned Lies

In addition to this localization cycle, our internationalization platform has improved. I shared a full changelog on the project release page. The most important features you will notice are:

• the ability to use git worktrees for big modules. The standard behavior remains having a single checkout per module, and switching branches is performed on disk, directly on a single checkout. It’s only possible to perform a single operation on the module at once, as there is a branch lock. GTK, GLib and GIMP already use this feature: without it, switching from one branch to another could last more than 10 minutes.
• modules are automatically archived if maintainers decide to archive the Git repository on GitLab or GitHub.
• a welcome message is now sent to new team members. Coordinators have to set it from the team detail page.
• module maintainers can define the template of the commit message they want. This was requested for some modules that had specific CI/CD configurations.

AI contributions

I received some contributions during this cycle that were LLM-assisted: either the code was generated by an LLM, or an LLM was used to analyze the codebase and detect defects. Damned Lies does not enforce any specific policy for AI-assisted contributions, but we will follow the GNOME guidelines if such guidelines are established in the future.

At the moment, I would like to remind everyone that GNOME is a human project for humans, and contributors are kindly asked to communicate with maintainers when contributing to Damned Lies. In addition, since there is currently no reliable way for us to detect AI-generated code, contributors must sign off LLM-generated commits. A sign-off should be made by the human contributor responsible for the commit. For example:

i18n: update translation handling Update the translation handling to support the new workflow.  Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jane Doe <jane@example.com>

 

Let’s start working on the next GNOME version!

Version:7.2.9 (stable) Released:2026-10-03 Source:linux-7.2.9.tar.xz PGP Signature:linux-7.2.9.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-7.2.9

Version:6.18.55 (longterm) Released:2026-10-03 Source:linux-6.18.55.tar.xz PGP Signature:linux-6.18.55.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.18.55

Version:6.12.112 (longterm) Released:2026-10-03 Source:linux-6.12.112.tar.xz PGP Signature:linux-6.12.112.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.12.112

Version:6.6.158 (longterm) Released:2026-10-03 Source:linux-6.6.158.tar.xz PGP Signature:linux-6.6.158.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.6.158

Version:6.1.189 (longterm) Released:2026-10-03 Source:linux-6.1.189.tar.xz PGP Signature:linux-6.1.189.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.1.189

Version:5.15.222 (longterm) Released:2026-10-03 Source:linux-5.15.222.tar.xz PGP Signature:linux-5.15.222.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.15.222

Version:5.10.271 (longterm) Released:2026-10-03 Source:linux-5.10.271.tar.xz PGP Signature:linux-5.10.271.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.10.271

LiteLLM has patched a privilege-escalation flaw that can let an authenticated internal user forge an administrative session and reach command-execution features in some AI gateway deployments.

Apache released HTTP Server 2.4.69 on October 1, 2026, to fix security faults ranging from unwanted code execution to mishandled web responses.

Apache detailed two Apache APISIX vulnerabilities in notices issued on October 1, 2026.

Apache disclosed CVE-2026-94250 on October 1, 2026, warning that public access to a batch-request endpoint can let an attacker exhaust a gateway worker's memory.

Apache's September 30, 2026 advisory, CVE-2026-88789, warns that an XML document can make an affected Camel Quarkus application read files or contact internal services.

Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.

The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.

There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.

Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.

Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)

AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.

That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.

Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.

I propose the following:

• GNOME maintainers should rewrite their AI contribution policies to permit AI-generated vulnerability reports, as I previously requested four months ago.
• Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.

We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.

Shouldn’t humans rewrite AI-generated bug reports?

When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.

Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.

Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.

Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.

The CVE Wave Hits GNOME

The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:

YearGNOME CVEsGNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt202121142022146202313420243728202597492026 Year-to-date (2026-09-30)141742026 Normalized188 (141 * 4 / 3)99 (74 * 4 / 3)

The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.

(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)

Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.

The CVE Wave Hits WebKitGTK

A similar pattern holds for WebKitGTK:

YearWebKitGTK CVEs2015175201657201715820181012019992020382021522022502023452024382025662026 Year-to-date (through WSA-2026-0006)305

CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.

There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.

I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.

Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program

My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)

The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.

I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:

YearReports SubmittedReports Accepted20242614202515033202612224Total29871

Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.

After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.

At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.

Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.

Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.

Lessons from the Bug Bounty Program

Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.

I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.

I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.

A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.

Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.

Red Hat Scans GLib

Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.

Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.

I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.

It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.

Humans Still Useful

In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in critical findings.

Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.

Humanity Still Desired

Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.

We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.

Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:

• Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
• Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
• Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
• Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.

Maintain Perspective

Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.

I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.

Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.

Rust

Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.

Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.

To Be Continued…

I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.

As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).

Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:

Hi, I request a CVE for: Summary: Requirements to exploit: Component affected: Version affected: All versions <-- change this if needed Patch available: Yes/No Version fixed (if any already): Upstream coordination: See issue report (below) CVSS (optional): Impact (optional): Embargo: No Acknowledgment: Steps to reproduce if available: see issue report Mitigation if available: <-- it's OK to write "None" Original report:

Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.

GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.