It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.
For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.
I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
Injection vulnerabilities, like cross-site scripting (XSS) or command injection, occur when we fail to properly encode untrusted output when inserting it into a trusted context. Before injecting uncontrolled or untrusted data, it’s essential to encode, escape, or quote the data to prevent it from breaking out of its intended context.
Some security folks previously used to like to talk about “input sanitization.” In practice, input sanitization is hopeless. Instead, nowadays we do the opposite and think about “output encoding.” When you inject untrusted data into a new context, assume the data is always malicious, and encode, escape, or quote it to make it safe for use in that context. Let’s look at some examples.
Pango Markup Injection
Here’s a low-stakes example of Pango markup injection:
The untrusted data is not escaped and may decide to inject its own Pango markup, or break out of any markup that you used yourself. For example, if the data is </b><span foreground="blue" size="x-large">Hello world!</span><b> then it can decide to be blue and extra large instead of the intended bold. That’s not especially serious and probably not likely to be a security issue, but surely it’s an unintended bug. If you’re injecting an uncontrolled string into a Pango markup context, like a GtkLabel, then use g_markup_escape_text() first. (Pango markup can do other interesting things like hide characters or capitalize them. I’m not sufficiently creative to claim that’s definitely a security problem, but perhaps attackers will be more clever than me.)
A real-world example: in this GNOME Shell issue report, the title of a desktop notification is able to use Pango markup to manipulate its own formatting. (At least, probably, because the issue report is unconfirmed. Looks plausible, though!)
Unix Shell Command Injection
Another good example is the Evince command injection vulnerability from a few months ago, where a malicious filesystem path is able to trick Evince/Atril/Xreader into executing arbitrary code. Evince expects the path of a file to open to be something like /home/foo/hello.pdf, but a malicious PDF instead provides the evil input --gtk-module=/home/foo/evil.so /home/foo/hello.pdf. If not quoted properly, we have a command injection vulnerability where --gtk-module is interpreted as a command line flag rather than as a path:
With that primer out of the way, let’s consider what happens when you inject untrusted content into HTML (or CSS, or JavaScript).
I used to think XSS matters only for websites, and is surely not something that desktop app developers need to know about, right? Wrong, as I discovered five years ago when, to my surprise, Prakash (@1lastBr3ath) reported that websites could inject scripts into Epiphany’s new tab page (about:overview) via malicious page titles. This on its own is not especially serious, but it’s surely not supposed to be possible.
If your desktop app uses WebKitGTK or another web engine, you probably do need to think carefully about XSS. For example, before injecting untrusted data into HTML, we need to HTML-encode it, which Epiphany didn’t do anywhere. In the simplest case, that looks like this:
Simply replace the few dangerous characters with HTML entities, and you’re good to go. That doesn’t work for HTML attributes, though, where the rules are slightly different. And it definitely doesn’t work for CSS or JavaScript. Carefully review the OWASP Cross Site Scripting Preventing Cheat Sheet to understand what you can and cannot do.
Recent XSS Bugs in Epiphany
Anyway, back to the old about:overview bug report. Turns out, Epiphany had many similar vulnerabilities. I attempted to fix them all, but in fact, I had missed a spot. In this old commit, I recognized that a URL is untrusted data that must be encoded before I inject the URL into the error message. But I treated the error message of the GError returned by WebKit as if it’s trusted and does not need to be encoded. In fact, the error message itself may contain a URL! Oops. Fernando Munoz recently noticed and reported several example URLs that could inject content into Epiphany error pages. I’m unable to share my favorite example URL here on WordPress, because WordPress is sanitizing it (yes, that is indeed ironic, considering my above recommendation to not do that). But the result of the injection looks like this:
So an evil URL can mess up the Epiphany network error page. That’s not particularly serious, but Fernando found a second injection that is much worse, an XSS vulnerability in Epiphany’s autofill implementation. Here, selector is formed using an untrusted DOM element ID provided by the web page itself. Notice that no output encoding is performed before the untrusted value is injected into the JavaScript command:
Because the untrusted data here is already used as a quoted data value, one of very few cases where it is safe to inject untrusted data into JavaScript, this would actually have been safe if only Epiphany had JavaScript-encoded the value first, following the OWASP rules for JavaScript encoding: “Encode all characters using the Unicode \uXXXX encoding format, where XXXX represents the hexadecimal Unicode code point. For example, A becomes \u0041. All alphanumeric characters (letters A to Z, a to z, and digits 0 to 9) remain unencoded.” But Epiphany did not do so. (I got confused by the OWASP rules and didn’t realize how easy it was to make this safe, so I fixed it in a more complicated way instead, by removing the need for injecting the form ID.)
So how bad is this mistake? In Fernando’s example, the ID of the evil form element is "a'); alert('XSS in private world'); var _=('", allowing the malicious website to run any script it wants. That might not seem so serious, because websites don’t need to exploit any vulnerabilities to execute JavaScript… right?
Script Worlds
Websites are only supposed to be able to execute JavaScript in the default script world. Think of a script world as basically just a big namespace for all of your JavaScript: the default world is what the website itself uses, but desktop applications can create their own private script worlds in order to run their own scripts. In a private script world, you can manipulate the page’s DOM as usual, but you have a separate environment for executing JavaScript code, so you don’t have to worry about name clashes or scripts conflicting with each other. Also, website scripts cannot access your scripts.
In practice, web browsers inject their own scripts into every web page in order to implement various browser features. Epiphany uses a script to find the best web app icon for a web page, for example. These scripts use a private script world that websites should never themselves have access to. But in this XSS attack on Epiphany’s form autofill implementation, the malicious website has managed to execute its script in the private script world. Now it can access whatever internal web browser features are available in that script world.
Unfortunately, there’s one more relevant Epiphany feature implemented using scripts: the password manager. Epiphany’s password manager is necessarily exposed to its private script world because Epiphany needs to execute JavaScript code in the web page in order to autofill passwords. Although there were no relevant bugs in Epiphany’s password autofill code (which is totally unrelated to its vulnerable generic form autofill feature), this did not matter: if an XSS bug in any Epiphany feature can be abused to execute code in Epiphany’s private script world, that code can access the password manager and exfiltrate all the user’s saved Epiphany passwords for every website. (At least, probably, because I have not set up an attack website to test this. But I don’t see why it wouldn’t work!) So that’s pretty serious.
Conclusion
I requested a CVE for the autofill vulnerability earlier today, but nowadays CVE requests usually take a couple of weeks, so I don’t have one yet. It is fixed in Epiphany 50.6 and 49.9. If you don’t have those versions yet, don’t panic. To be exploited, you have to manually trigger form autofill by right clicking on a form and then selecting either “Autofill Personal Fields” or “Fill This Field,” so that makes it much less scary. Even more fortunately, users probably won’t ever do that, because selecting either option always causes Epiphany to reject all further mouse input, becoming unusable. Nobody has reported this bug before, so it seems safe to conclude zero people are using Epiphany’s form autofill feature!
Update: I said it would take a couple of weeks, but a few hours later I received CVE-2026-77682. Red Hat has improved its response time!
Due to the increase in AI-generated security vulnerability reports, it is time for some changes in how GNOME manages vulnerability reports.
These policy changes intentionally do not distinguish between reports that contain AI-generated content and those that do not. Following the same rules for all vulnerability reports is simpler than having two different ways of doing things. Reporters rarely disclose AI use, and it’s nice to not have to guess whether the issue report is AI-generated or not; it’s normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn’t make sense to optimize for them.
Reduced Disclosure Deadline
Traditionally, I have applied a 90 day disclosure deadline to all security issues reported to GNOME Security. 90 days is an industry standard timeline, but it doesn’t work particularly well for GNOME. In practice, almost all GNOME maintainers handle vulnerability reports in one of two ways:
The project maintainer fixes the issue quickly, typically within 1-3 weeks after it is reported.
The project maintainer does not fix the issue at all. The issue report eventually reaches the 90-day disclosure deadline, at which point I unset confidentiality.
The 90-day deadline is intended to allow project contributors time to fix the issue before it becomes public, but in practice, maintainers do not actually make use of most of this time. I disclose the issue report and request a CVE when it is fixed or when the disclosure deadline is reached, whichever comes first. Once a CVE is assigned, contributors who are not regular project maintainers will sometimes attempt to fix it. Accordingly, keeping the issue reports confidential for 90 days only introduces a delay that is not useful.
Some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for issue reports that seem to be AI-generated, on the basis that a vulnerability that can be discovered by AI is presumably already known to attackers. But this policy seems pretty extreme, and is certainly unkind to maintainers who might feel pressured to urgently fix the issue. Immediate disclosure would not work well for GNOME.
Instead, I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports.
Procedure for Projects that Prohibit AI-Generated Content
If a project prohibits issue reports that contain AI-generated content, I will no longer forward security issues reported to GNOME Security to the project’s issue tracker, since the overwhelming majority of vulnerability reports contain AI-generated content and would violate the project’s policy. Instead, I will immediately close the issue report in the GNOME Security issue tracker, then ping the project maintainers to let them know about the existence of the report. If you prefer to receive vulnerability reports in your project’s issue tracker, then please change your project’s AI policy to make an exception for vulnerability reports.
Unfortunately, GNOME maintainers don’t have access to confidential issues in this issue tracker, and GitLab does not allow CCing individual developers on confidential issue reports. I had been planning to adopt immediate disclosure for these issues only, but perhaps we should instead expand the permissions to allow all GNOME developers to see the issue tracker. Opinions welcome.
Moving On
I have been managing GNOME security issue tracking since November 2020. (Thank you to Red Hat for supporting this work.) Security tracking is largely a secretarial duty: I keep track of issues when they are reported and when they are closed, disclose them when the deadline is reached, and request CVEs when appropriate. It is not a huge amount of work, but I am getting tired of it, so it’s time for a change. I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)
This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It’s easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.
GNOME developers have long used G_GNUC_CONST, which expands to __attribute__((const)), to annotate GObject _get_type() functions, despite knowing that it is incorrect to do so. const functions by definition have no side effects, but _get_type() functions actually have a side effect the first time the function is called: they initialize the type. Why apply an incorrect annotation to these functions? Because it makes the code faster.
Although this was long known to be incorrect, it worked fine in practice… until now. Regrettably, Sam James has discovered that GCC 16 may optimize away the type initialization, resulting in crashes. This is our fault for providing the compiler with wrong information about our code, so it’s time to audit your use of const attributes to remove them from _get_type() functions. Most GNOME programs use these attributes only for _get_type() functions, but if you use it in more places, then check to make sure those functions are actually const, as defined by the GCC documentation.
Sadly, there is no suitable replacement attribute for _get_type() functions. Two decades ago, Behdad requested a new idempotent attribute for expressing the desired semantics, but nobody has implemented it.
This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.
This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.
AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.
I won’t attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That’s probably inadvisable, but I am not going to object.
But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don’t do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project’s AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.
It’s hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.
2. Resource leak in update_credentials_cb on gnutls_credentials_set failure
File: tls/gnutls/gtlsconnection-gnutls.c:169-172
When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.
Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?
I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.
As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it’s more likely that either (a) you won’t receive the issue report in the first place, or (b) you won’t receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.
What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the “over 100” claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.
Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it’s really bad, then I sometimes don’t even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.
CVE-2026-46529 is an argument injection vulnerability in Evince, Atril, and Xreader caused by missing shell quoting when composing a command line. The reporter, João Medeiros, has published a GitHub repo for the CVE and a blog post with the story of how he discovered the flaw and developed the exploit. He also created an Atril security advisory and an Evince issue report.
The vulnerability is fixed in:
Evince 48.4 (fix commit) (I originally reported that it is fixed in 48.2, but there was no successful release for that tag)
The Flatpak sandbox could have drastically reduced the danger of this attack, limiting the compromise to only files that you had previously opened in the PDF reader. Sadly, Evince and Papers both use sandbox holes that render the sandbox totally meaningless. (Atril and Xreader are not available on Flathub.)
The Vulnerability
When you click on a link in a PDF, Evince may execute itself to display the link. Normally the command line used would look something like this:
/usr/bin/evince --named-dest=/home/foo/hello.pdf
But an evil PDF may trick Evince into executing a command that is quite different than expected:
Oops. The first part of the command is always going to be /usr/bin/evince, but the evil PDF is nevertheless able to unexpectedly load a GTK module into Evince. The fix is to quote the untrusted input using g_shell_quote() to ensure it cannot “break out” of its intended context:
Much better: now the threat is neutralized. g_shell_quote() is safe to use even if the untrusted input itself contains quotes. (However, beware: this only works because GLib is parsing the command line itself, and GLib is not a real Unix shell. It’s not safe if the input is going to be passed to an actual Unix shell. It might not even be theoretically possible to do that safely, because it’s valid for filenames to contain entirely arbitrary characters!)
All GTK 3 apps support the --gtk-module command line argument for injecting a shared library into the application. The library may of course then execute whatever code it wants via its library constructor. But GTK 4 no longer has standard GTK command line flags, so this does not work for GTK 4 applications like Papers. It’s still possible to tell a GTK 4 app to load a GTK module, but only via environment variables, not via command line flags, and I don’t see any opportunity for the malicious command to set environment variables. It’s probably not possible to exploit this vulnerability in Papers: although it has the exact same vulnerability as the other PDF readers, the impact is different.
The Exploit
So far this looks like a pretty typical security bug. OK, so if you trick the user into downloading an archive (or perhaps a git repo) that contains both a malicious PDF and also a malicious shared library, then you can trick the PDF reader into loading the shared library and thereby execute arbitrary code. That’s a pretty bad foreseeable exploit, sure, but at least the attacker is at considerable risk of arousing suspicion if the user is trying to download a PDF and also receives a shared library. You’d have to try pretty hard to hide the library in a forest of other boring files if you want the attack to look convincing and unsuspicious. Right?
Nope.
João used Claude Opus 4.7 to develop a sophisticated script for building malicious polyglot PDFs that are simultaneously both valid PDF files and also valid ELF binaries, so the attacker only needs to trick the victim into downloading one evil PDF file. When the victim clicks on a link in that PDF, the PDF reader will dlopen the PDF itself. The PDF/ELF polyglot’s library constructor will then execute arbitrary code. Much less suspicious, and much scarier. Polyglot files are not entirely novel, but I’d still say this required substantial creativity and expertise from the AI, and substantial persistence from the human. Needless to say, very nice job to both Claude and João.
You can easily build your own malicious PDF using the provided script and sample GTK module. The script in the Evince and Atril issue reports requires that the attacker predict the absolute path that the malicious PDF file will be saved to; however, João’s blog post and GitHub repo refine the exploit to remove that requirement.
Thoughts on AI Vulnerability Reports
A human inspecting this code should have been able to find the parameter injection vulnerability, but that requires considerable time and effort, so unsurprisingly nobody did. We’re probably in for a rough time in the short term as the volume of AI-generated vulnerability findings remains temporarily very high and attackers have a much easier time crafting working exploits. But in the long term, I expect we are going to be much more secure than we were before, so this will be worth it.
A human working alone would have almost certainly stopped and moved on after finding the vulnerability. Claude allowed taking the investigation much farther. It’s highly unusual for a GNOME vulnerability report to come with a working exploit. This is a dangerous change. Perhaps it will be a one-time event, but I suspect we will be seeing more frequent exploits in the future.
Silver lining: the exploit helps us better appreciate the severity of the issue. It’s often hard to assess how bad a vulnerability is. If not for the weaponized exploit, I would have thought this bug was not very scary, and would have treated it as not a big deal. We would have fixed it, perhaps or perhaps not with a CVE ID, surely without any blog post or fanfare, and probably without distro security updates. But since there is an exploit, we instead had no doubt that this vulnerability was dangerous, and were able to handle it accordingly.
Several GNOME projects have begun outright prohibiting all AI-generated contributions, including issue reports, with no exception for vulnerability reports. Such policies are misguided and unacceptable. I can sort of understand why some projects might (misguidedly) wish to prohibit AI-generated code contributions. OK, fine. But blocking AI vulnerability reports will make GNOME less safe. AI-assisted vulnerability reporting is the new industry standard for good reason: it is highly effective.
Some humans are not good at preparing AI-assisted vulnerability reports and will spam maintainers with low-quality reports. Sometimes they will be outright bogus, although more often there may be valid underlying bugs with exaggerated severity claims or bad proof of concept demos. This is annoying, but bad issue reports are a cost we are just going to have to accept and deal with.
The quality level of AI vulnerability reports reviewed by conscientious humans — as well as AI assessments of AI vulnerability reports — is now often quite encouraging. But just like humans, AIs may also miss things, especially subtle distinctions that may be highly relevant. Although I’m quite impressed with these AIs, we still need experienced humans to review and manage reports. Please don’t abuse the technology by submitting vulnerability reports that you do not understand or have not validated. And certainly please do not allow an AI agent to interact with an issue tracker on your behalf!
For Security Geeks
This was my first time scoring a vulnerability using CVSS 4.0 rather than CVSS 3.1. It’s also the first time I wasn’t terribly confused about how to set the parameters, because the scoring guide contained answers to all of my questions. Nice. My CVSS vector for CVE-2026-46529 is CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, the base score is 8.4, and I’m pretty sure my choices for each parameter are good. By comparison, using CVSS 3.1 I came up with CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and base score 7.8.
Yelp 49.1 fixes a significant Flatpak sandbox escape related to last year’s CVE-2025-3155. CVE assignment for this new issue is currently pending. June 29, 2026 update: better late than never, we have received CVE-2026-13601.
This is not a bug in Flatpak. Flatpak allows sandboxed applications to open URIs or files, meaning the sandboxed application may use a URI or file path to launch another application to open the URI or file. This is brokered via the OpenURI portal. The portal or the app may decide to require user interaction to decide which app to launch, but user interaction is generally not required. This is necessary: you would get pretty frustrated if you were prompted to select which app to use every time you click on a link or try to open something! Accordingly, unsandboxed applications that are installed on the host system are somewhat risky: any malicious sandboxed app may launch an unsandboxed app using a malicious file, generally with no user interaction required. Unsandboxed applications installed on the host OS are inherently part of the attack surface of the Flatpak sandbox.
In this case, a sandboxed application may launch Yelp to open a malicious help file. The help file can then exfiltrate arbitrary files from your host OS to a web server by using a CSS stylesheet embedded in an SVG. Suffice to say the attack is pretty clever, and certainly more impactful than the typical boring memory safety bugs I more commonly see.
This bug was discovered by Codean Labs, which performed a security audit of Flatpak and several GNOME projects thanks to generous sponsorship by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency.
If you work with patches and git am, then you’re probably used to seeing patches fail to apply. For example:
$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
error: patch failed: gio/gfileattribute.c:166
error: gio/gfileattribute.c: patch does not apply
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
This is sad and frustrating because the entire patch has failed, and now you have to apply the entire thing manually. That is no good.
Here is the solution, which I wish I had learned long ago:
$ git config --global am.threeWay true
This enables three-way merge conflict resolution, same as if you were using git cherry-pick or git merge. For example:
$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
Using index info to reconstruct a base tree...
M gio/gfileattribute.c
Falling back to patching base and 3-way merge...
Auto-merging gio/gfileattribute.c
CONFLICT (content): Merge conflict in gio/gfileattribute.c
error: Failed to merge in the changes.
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Now you have merge conflicts, which you can handle as usual. This seems like a better default for pretty much everybody, so if you use git am, you should probably enable it.
I’ve no doubt that many readers will have known about this already, but it’s new to me, and it makes me happy, so I wanted to share. You’re welcome, Internet!
WebKitGTK 2.50.3 contains a workaround for CVE-2025-13947, an issue that allows websites to exfiltrate files from your filesystem. If you’re using Epiphany or any other web browser based on WebKitGTK, then you should immediately update to 2.50.3.
Websites may attach file URLs to drag sources. When the drag source is dropped onto a drop target, the website can read the file data for its chosen files, without any restrictions. Oops. Suffice to say, this is not how drag and drop is supposed to work. Websites should not be able to choose for themselves which files to read from your filesystem; only the user is supposed to be able to make that choice, by dragging the file from an external application. That is, drag sources created by websites should not receive file access.
I failed to find the correct way to fix this bug in the two afternoons I allowed myself to work on this issue, so instead my overly-broad solution was to disable file access for all drags. With this workaround, the website will only receive the list of file URLs rather than the file contents.