ori_b's post to the oss-security mailing list directly calls out the PostgreSQL project for publicly disclosing the CopyFail vulnerability without going through the standard linux-distros@vs.openwall.org pre-notification channel. The post argues this left major distributions like Debian, Ubuntu, and Red Hat without the typical 7-14 day window to prepare patched packages before public exposure.
The editorial emphasizes that PostgreSQL is the most-used database per Stack Overflow's 2025 survey, deployed across everything from side projects to bank transaction systems. The window between public vulnerability disclosure and patched package availability is described as 'the most dangerous window in security,' making the lack of distro pre-notification especially consequential for an infrastructure component this widely deployed.
The editorial describes the vulnerability as involving improper handling of the CopyFail message path in PostgreSQL's COPY sub-protocol, where an attacker could exploit error string processing during a COPY FROM STDIN abort in ways the protocol designers never intended. While the process failure dominates discussion, the underlying technical flaw in wire protocol message handling represents a genuine exploitable attack surface.
On April 30, 2026, a post to the oss-security mailing list at openwall.com called out the PostgreSQL project for publicly disclosing a vulnerability nicknamed "CopyFail" without pre-notifying Linux distribution security teams through the standard coordinated disclosure channels. The post, archived at the oss-security list, immediately drew attention — hitting 456 points on Hacker News within hours.
The vulnerability itself relates to PostgreSQL's COPY sub-protocol, specifically the CopyFail message path. In the PostgreSQL wire protocol, when a client initiates a `COPY FROM STDIN` operation and needs to abort, it sends a CopyFail message containing an error string. The vulnerability appears to involve improper handling of this error path, potentially allowing an attacker to exploit the message processing in ways the protocol designers never intended.
The technical severity aside, the firestorm is about process. The standard practice for vulnerabilities in widely-deployed open-source infrastructure is to notify distribution security teams — via the linux-distros@vs.openwall.org or distros@vs.openwall.org mailing lists — before public disclosure. This gives Debian, Ubuntu, Red Hat, SUSE, Arch, and others a window (typically 7-14 days) to prepare patched packages so that when the CVE goes public, users can immediately `apt upgrade` or `dnf update` their way to safety.
That didn't happen here.
PostgreSQL isn't some niche tool. It's the default production database for a significant portion of the industry. Stack Overflow's 2025 developer survey had it as the most-used database for the third consecutive year. When a Postgres vulnerability drops, it affects everything from solo founder side projects to banks running mission-critical transaction processing.
The coordinated disclosure process exists precisely because the gap between "vulnerability is public" and "patched package is available" is the most dangerous window in security. Attackers monitor oss-security, CVE feeds, and commit logs. The moment a vulnerability is public, the clock starts. If distro maintainers are learning about the bug at the same time as everyone else, they're scrambling to backport patches to multiple supported release branches while adversaries are already writing exploits.
The counter-argument from upstream projects is not without merit. Coordinated disclosure with distros means trusting dozens of organizations with embargoed information. Leaks happen. The linux-distros list has had embargo breaks before, and some projects argue that a rapid public disclosure with a patch available from upstream is safer than a long embargo period where the vulnerability might leak to attackers before it leaks to the public.
There's also a philosophical divide. Some PostgreSQL community members have historically argued that their own security process — which involves a coordinated release date across all supported branches with patched tarballs available at disclosure time — is sufficient, and that distro notification is the distros' problem, not upstream's. This view holds that if Debian or Red Hat can't turn around a package rebuild within hours of an upstream release, that's a packaging infrastructure problem.
The distro maintainers see it differently. Building, testing, and shipping security updates across multiple release branches, architectures, and derivative distributions is non-trivial work. A 7-day heads-up isn't a luxury — it's what allows a security update to land on users' systems the same day the CVE is published.
This incident reopens a long-running tension in open-source security governance. The openwall distros list has explicit policies: embargoes should be short (max 14 days for linux-distros, max 19 days for the broader distros list), and the list exists specifically for coordination, not for permission.
Projects that bypass the list tend to cite one of three reasons:
1. Speed: The bug is being actively exploited and any delay is unacceptable 2. Scope: The project doesn't consider the bug severe enough to warrant the coordination overhead 3. Policy: The project has its own disclosure process and doesn't participate in the distros list as a matter of principle
For PostgreSQL specifically, this isn't the first time the question has come up. The project maintains its own security team with a well-defined process: reporters submit to security@postgresql.org, the team triages and develops fixes, and coordinated releases happen across all supported major versions simultaneously. The process is genuinely good — the question is whether "good upstream process" and "distro pre-notification" are complementary or redundant.
The HN discussion, predictably, splits along tribal lines. Database administrators and ops engineers who manage distro-packaged PostgreSQL are frustrated. They rely on `apt` and `dnf` as their patch delivery mechanism, and a surprise disclosure means they're exposed until their distro ships the update. Developers who compile from source or use containers with official Postgres images are less bothered — they can pull updated images within minutes of an upstream release.
If you're running PostgreSQL in production — and statistically, many of you are — here's what to do right now:
Check your version. Run `SELECT version();` on your production instances. If you're on a version affected by CopyFail and haven't patched, do so immediately. If you're waiting for your distro's package, check whether the upstream tarball or official Docker image is already patched and consider whether an out-of-band update is warranted for your risk profile.
Audit your COPY usage. The CopyFail vulnerability sits in the COPY protocol path. If your application doesn't use `COPY FROM STDIN` (or uses it only from trusted internal services), your exposure may be limited — but don't assume this without checking. Connection poolers like PgBouncer and application frameworks that abstract database access may use COPY in ways you don't expect.
Re-evaluate your patch delivery pipeline. This incident is a reminder that relying solely on distro packages for security-critical infrastructure introduces a dependency on the distro's response time. For your most critical databases, consider whether you should track upstream releases directly and have a tested process for out-of-band patching. Container-based deployments have an advantage here — updating a base image tag is often faster than waiting for a distro package.
The CopyFail disclosure gap will likely produce some concrete outcomes. Expect renewed discussion on the pgsql-hackers mailing list about formalizing distro pre-notification as part of PostgreSQL's security process. The openwall community will probably update their documentation to list PostgreSQL's current stance for transparency. And distro security teams will add this to their growing list of examples when arguing for mandatory pre-notification in open-source security policies. Whether any of that actually changes PostgreSQL's process depends on whether the project's security team sees this as a legitimate failure or an overreaction to a process that, from their perspective, worked fine upstream.
> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux p
The most interesting exchange, related to disclosure, is this one:https://www.openwall.com/lists/oss-security/2026/05/01/3> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone abo
Stop blaming the reporter. Start asking kernel to fix their process. Linux kernel is no longer a toy project, it has full time employees employed by various companies. They should have handled notifying distributions. Not some rando.
Just for what it's worth, I just pushed an eBPF-based workaround for people who are running kernels in which AF_ALG is linked directly into the kernel and not as a module: https://github.com/Dabbleam/CVE-2026-31431-mitigationI am running this in production right now and it m
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
For context, the author of the linked post, Sam James, is a Gentoo developer.Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.It's also worry