Brief items
Security
Critical WordPress RCE vulnerability announced
A critical vulnerability has been discovered in WordPress's get_page_template() function for page-template resolution that could allow remote-code execution (RCE) by an unauthenticated attacker, in some limited circumstances. The project has provided an update for the most recent branch of WordPress, as well as backports of the fix for branches back to 4.7. See the vulnerability report for the conditions required for an RCE attack to be successful.
The vulnerability also affects the ClassicPress fork of WordPress, though a security update has not been provided for that project yet. LWN covered ClassicPress in 2024. Users of either content-management system should update soon.
Critical security vulnerabilities in the Radicle network protocol
The Radicle peer-to-peer
code-collaboration project has disclosed
two critical vulnerabilities in the network protocol used by Radicle
nodes. The first flaw is that the network protocol used by Radicle "does not
give the confidentiality it was expected to give
", which allows anyone who
can observe the network between two nodes to read the data exchanged. The second
is that peer authentication is broken and allows impersonation, so an attacker
can spoof their Node ID and read private repositories they should not be able to
read.
In practice, the two flaws are most useful when they can be exploited together: an attacker on the path sees the Node IDs at both ends of a connection, and both are normally on the allow-list. That attacker can read whatever is exchanged while they watch, and can then use a Node ID they saw to fetch the whole repository on demand. The realistic threat is anyone on the path between your node and node it syncs with, and no setting or allow-list protects against them.
We are publishing this before the security update is available. You can act on it today, and no fix we release later can undo an exposure that has already happened.
See the post for workarounds that can be used today; a major update that will be backward-incompatible is underway.
Kernel development
Kernel release status
The current development kernel is 7.3-rc4, released on September 20. It is, unsurprisingly at this point, large; Linus said: "We all know the drill by now: 'it's big, yadda yadda'".
This release has seen 17,056 non-merge changesets from 2,720 developers, 649 of whom were first-time kernel contributors. The release history looks like:
RC Date Commits v7.3-rc1 2026-08-30 16267 16267 v7.3-rc2 2026-09-06 681 681 v7.3-rc3 2026-09-13 733 733 v7.3-rc4 2026-09-20 598 598
See the LWN KSDB v7.3 page for a lot more details.
Stable updates: the large 7.2.7, 6.18.53, and 6.12.111 updates were released on September 21.
Systemtap 5.6 released
Version 5.6 of the Systemtap tracing tool has been released.
BPF LSM hooks and XDP packet-processing probes for the --bpf runtime, BTF-based kernel.tracepoint probes, statement execution tracing, a new @enumname() operator, richer runtime error context, dyninst hardware watchpoints, modern systemd service templates, and broad Linux 7.2 runtime/tapset compatibility work. Multithreaded speedups throughout.
Development
GNOME 51 released
Version 51 of the GNOME desktop environment has been released. The list of changes includes a number of performance improvements, offline data and better transit information in the Maps application, a new interface for the file previewer, and more.Igalia celebrates "Twenty-Five Years Upstream"
The open-source consulting firm Igalia has put out an announcement celebrating 25 years of working on upstream FOSS projects for its clients. The list of projects the company has worked on is rather eye-opening: WebKit, mobile-browser rendering (on Maemo, Moblin, MeeGo, and Tizen), the Linux kernel (CPU and GPU scheduling), 3D graphics drivers, the Orca screen reader, GStreamer, and lots more. Beyond that, the company, which is a worker-owned cooperative, does its work in ways that benefit the community as well as its clients:None of this is charity. Igalia is a consultancy, and most of the work above was paid for by someone with a product to ship: a device maker who needs the web to run well on their hardware, a platform that needs a feature its users keep asking for, a company whose roadmap depends on something deep in the stack working better than it does today. What they get from us is not a patch to carry forever. We do the work upstream, in the project itself, so it arrives in the next release and keeps working long after the contract ends. Our customers ship products built on code that nobody has to maintain alone, and everyone else gets the same code. That has been the arrangement from the start.
Systemd v262 released
Systemd v262 has been released. Some of the notable new features include the ability to build systemd as a single statically linked binary for small containers, support for the kernel coredump socket protocol introduced with Linux 6.17, addition of OpenSSL 4 support, and many other changes. See the release notes for a full list of changes.
Development quotes of the week
In a software context, I think part of the Star Trek utopia we should be striving for (and a sign we've achieved it) is putting a wooden stake through the heart of the word "consumer."— Matilda Horger
— Tomas VondraLet's say you're working on a patch, and you want to post it to the list already. There's one more change needed, to fix a design issue. It'd take ~10 minutes of your time, but it's mostly mechanical, anyone can do it. So you post the patch without it, to get the feedback earlier.
This unfortunately has two likely consequences. Some reviewers will point out that one change - which you already planned to do, so it's not very useful feedback. And other reviewers will end up doing the change themselves, and now you've wasted 10 minutes of each reviewer's time.
If you can save time for other people, do it. It may be just 10 minutes of your time, but with multiple people it quickly adds up and it can be 1 hour of "community time."
Page editor: Daroc Alden
Next page:
Announcements>>
