PostgreSQL JDBC's October 2026 CVEs Explained: Fail-Open Auth and Padding Leaks

Your app believes it is protected while it is not. The PostgreSQL JDBC vulnerability CVE-2026-107314 is exactly that: a strict login rule the driver treated as no rule. Nothing crashed, so nobody noticed.

A JDBC driver is the library a Java program uses to talk to a database. pgjdbc is the PostgreSQL project's JDBC driver. Frameworks such as Spring Boot and Hibernate call a JDBC driver like pgjdbc underneath. You configure it with a JDBC URL, a connection string that names the server, the database and extra settings.

Picture a common setup. A team runs a GST invoicing service for small shops, with Java services on PostgreSQL and pgjdbc 42.7.12. GST is India's goods and services tax. The setup is made up, but both bugs are real.

In the same month, two problems reached the team. An audit asked them never to send a plain password to the database, so a contractor added a requireAuth value. Separately, a shop owner reported an invoice PDF whose last bytes held another shop's phone number.

The first problem is CVE-2026-107314 and the second is CVE-2026-107315. This guide follows both to the fix.

You need these terms, here in plain words. Each one comes back later.

• Authentication method: how the database checks who you are. pgjdbc knows six: password (sent as plain text), md5 (an older hashed challenge), scram-sha-256, gss, sspi and none.
• SCRAM-SHA-256 is a challenge-response proof that never sends the password. GSS usually means Kerberos, a ticket-based single sign-on system used in company networks. SSPI is a Windows-only cousin of GSS, and none means trust, with no password at all.
• requireAuth: a pgjdbc connection property listing the methods the driver will accept. A name with ! in front rejects that method. pgjdbc's docs say you cannot mix allowed names and ! names.
• Man-in-the-middle: an attacker on the network between your app and the database who pretends to be the database.
• Fail-open and fail-closed: when a check cannot decide, fail-open lets the connection through and fail-closed refuses it.
• Send buffer: memory where the driver collects bytes before sending them in one go. pgjdbc reuses one buffer for every message on a connection.
• Declared length and padding: some driver calls announce a value's size before sending it. Padding is the filler the driver adds when the real data is shorter than that promise.

It is two separate bugs, published together on 7 October 2026 as two GitHub security advisories, GHSA-rhp9-mr79-r74h and GHSA-f64h-wr5q-3qf3. One is a login rule that failed open. The other is a send buffer that leaked old bytes into stored values.

CVSS is a 0 to 10 severity score. The CVSS vectors say each attack works over the network, is hard to pull off and harms only confidentiality. The padding bug also needs low privileges, such as a normal app account.

The driver used one value, null (Java's empty value), for two opposite meanings. The advisory names the function AuthMethod.parseRequireAuth. It returned null both when requireAuth was not set and when the value left no method allowed.

A second function, AuthMethod.checkAuth, treated null as no restriction. So the driver accepted whatever method the server asked for, including a plain-text password.

The advisory's example value is !password,!md5,!gss,!sspi,!scram-sha-256,!none, which excludes all six methods. The order of the names and any spaces between them do not matter.

That was the team's value. The contractor meant to block the weak methods, but put ! in front of every method in the docs, scram-sha-256 included. The driver ignored the rule, so everything kept working.

A value made only of commas, such as a single comma, names no method and failed the same way. Positive lists like scram-sha-256 and partial exclusions like !password,!md5 were enforced. Apps that never set the property were not affected.

What the attacker in the middle does

At login, the PostgreSQL server picks the method and sends the client an authentication request. If it asks for a plain-text password, the protocol says the client sends the password as it is.

A man-in-the-middle can send that request itself. With the rule ignored, the team's driver would reply with its real database password. A rule that allowed only scram-sha-256 would have refused instead.

Encryption alone does not save you. TLS is the protocol behind your browser's padlock. pgjdbc's default sslmode, prefer, does not verify the server's certificate, so a fake server can still speak TLS.

Because whoever wrote a strict rule wanted strictness. The team's value even included !none, which pgjdbc's docs describe as rejecting trust logins. A rule that allows no method and also forbids skipping login can only mean refuse.

A rule that fails open never produces an error. Tests pass, users stay happy and the gap stays invisible until someone attacks it.

The deeper mistake was a sentinel, a special value that stands for a situation. Null meant both nobody set a rule and the rule allows nothing. Code that reads it later cannot tell the two apart.

SQLState is a five-character error code that SQL databases and drivers share. In 42.7.14, a value excluding every method fails with SQLState 08004, the standard code for a server rejecting a connection. pgjdbc reuses it when the driver itself refuses.

The message reads: Authentication method is not allowed by requireAuth. With channelBinding=require also set, you see the channel binding error instead, per the release notes. Either one is your check that the fix is live.

A value that names no method, such as a single comma, fails as invalid with SQLState 22023, the standard code for an invalid parameter value. Its message is Invalid authentication method, followed by the value.

That is what happened to the team. When they upgraded staging to 42.7.14, the PDF service failed with SQLState 08004. Changing its value to requireAuth=scram-sha-256 fixed it.

When a value was shorter than its declared length, versions 42.7.4 to 42.7.13 could fill the gap with bytes left in the send buffer from earlier messages. The server stored them as part of the value.

How a reused send buffer works

Imagine a courier who reuses envelopes without emptying them. If your letter is shorter than promised, old pages already inside fill the gap.

Map it like this: the envelope is the send buffer, the old pages are bytes from earlier statements and the promise is the declared length. Where the picture breaks: the driver did wipe the part it reused while the buffer held unsent data. Only an empty buffer skipped the wipe.

The PostgreSQL wire protocol is the message format the driver and server exchange. In a Bind message, which carries a statement's parameter values, each value states its length first, then sends exactly that many bytes. COPY, PostgreSQL's bulk-load command, sends data messages that also carry their length first.

So once the driver has announced 50,000 bytes, it must send 50,000 even if the app supplies only 49,000. Versions 42.7.3 and earlier padded the gap with zeros.

The buffer state that skipped the wipe

The advisory names the padding routine PgBufferedOutputStream.writeZeros. From 42.7.4 it only zeroed the part of the buffer it overwrote while the buffer held data. When the buffer was empty on entry, it zeroed nothing and sent the old contents.

The advisory gives two ways the buffer ends up empty. The previous write was big enough to bypass the buffer, leaving older bytes behind. Or the data ended exactly at a buffer boundary, so the buffer still held the last bytes sent.

The model below is a simplified Python sketch of that one branch, not the driver's Java code. It flushes a buffer that just held shop 1's data, then pads a value for shop 2.

buf = bytearray(16)   # one send buffer, reused for every message
count = 0             # bytes waiting in buf right now

def write(data):
    global count
    buf[count:count + len(data)] = data
    count += len(data)

def flush():
    global count
    sent, count = bytes(buf[:count]), 0   # old bytes stay in buf
    return sent

def write_zeros(n, fixed):
    global count
    if fixed or count > 0:
        buf[count:count + n] = bytes(n)   # wipe before reuse
    count += n

write(b"shop1 PH 98xx01"); flush()        # statement A, then a flush
write_zeros(15, fixed=False); print(flush())  # padding for shop 2, old driver
write_zeros(15, fixed=True); print(flush())   # padding for shop 2, fixed driver

Run it with python3 and it prints two lines. The first is b'shop1 PH 98xx01', shop 1's data sent as shop 2's padding. The second is 15 zero bytes, which is what 42.7.14 sends.

What just happened: the flush reset the count of waiting bytes but left the memory alone. The old check only wiped when the count was above zero, so the stale bytes went out.

Driver calls that declare a length

The advisory lists these entry points, and the driver accepts them without an error even when the data runs short.

• PreparedStatement.setObject with a ByteStreamWriter, a pgjdbc helper that streams bytes, when getLength() promises more than writeTo() writes.
• CopyIn.writeToCopy with a ByteStreamWriter or a byte array, and PGCopyOutputStream.write for writes over 64 KiB.
• LargeObject.write, and java.sql.Blob.setBytes, which calls it. Large objects are PostgreSQL's way to store big binary files.

For the byte-array calls, the trigger is a length that runs past the end of the array. The team's PDF service took its declared length from the upload's Content-Length header, the size the uploading client said it would send.

How much can leak, and why range checks are not enough

With default settings, each padded value can carry up to 8,192 bytes of earlier traffic. That is the default maxSendBufferSize, a connection property added in 42.7.4.

With GSS encryption turned on through gssEncMode, the advisory says padding can carry up to 16,320 bytes with MIT Kerberos. On a connection pool, a shared set of open connections, those bytes can come from other users' requests.

The advisory also explains why range checks alone would not fix it. A range check rejects an offset or length that runs past the end of a byte array. It cannot catch a ByteStreamWriter that writes less than it promised, because the driver has already sent the length. So the fix zeroes the buffer from its start up to the padding length, or all of it if the padding is longer.

Every version from 42.7.4 to 42.7.13 needs 42.7.14 for the padding bug, and 42.7.11 to 42.7.13 also have the requireAuth bug. Upgrading fixes the driver, but two checks remain in your own code and data.

1. 1

   Find the version you really run

   Check the resolved dependency tree for org.postgresql:postgresql, pgjdbc's name in Maven Central, Java's main package registry. Framework dependency management or another library can pick a version for you, and app servers may hold their own copy.

2. 2

   Upgrade to 42.7.14

   Pin 42.7.14 or later and redeploy every service, including batch jobs and admin tools.

3. 3

   Search every config for requireAuth

   Check JDBC URLs, properties files, environment variables and secret stores. Replace all-excluded or comma-only values with a positive list.

4. 4

   Lock down the network path

   Use sslmode=verify-full, with the server's CA certificate on the client. Where the server offers SCRAM-SHA-256-PLUS, the channel-binding form of SCRAM, add channelBinding=require.

5. 5

   Audit declared lengths

   Find the calls listed above. Make each declared length match the bytes you send, and reject short uploads early.

6. 6

   Review values already stored

   Rows written through those calls by 42.7.4 to 42.7.13 may hold leaked traffic. The next section covers what to do.

How to confirm the version you ship

In Gradle, run gradle -q dependencies --configuration runtimeClasspath (or ./gradlew with the same arguments) and look for the postgresql line. A fixed build shows org.postgresql:postgresql:42.7.14.

If your build asks for 42.7.14 and another library asks for an older one, Gradle prints both on one line with an arrow between them. The older one comes first and the version it chose second, here 42.7.12 then 42.7.14. A line with no arrow is the version you ship. When only a library brought in 42.7.12, our stub project on Gradle 8.14.3 printed a plain org.postgresql:postgresql:42.7.12, which still needs the upgrade.

In Maven, mvn dependency:tree -Dincludes=org.postgresql:postgresql prints a line in the form org.postgresql:postgresql:jar:VERSION:SCOPE, per the Maven dependency plugin docs.

A requireAuth audit you can run

This script checks requireAuth values against the advisory and the parser in pgjdbc's 42.7.13 source, AuthMethod.parseRequireAuth. Copy the values from your configs into service_values before running it.

METHODS = {"password", "md5", "gss", "sspi", "scram-sha-256", "none"}

def split_like_java(value):
    parts = value.split(",")
    if "," in value:                 # Java drops trailing empty pieces
        while parts and parts[-1] == "":
            parts.pop()
    return [p.strip() for p in parts]

def check_require_auth(value):
    parts = split_like_java(value)
    if not parts:
        return "BAD: names no method, fails open on 42.7.11 to 42.7.13"
    negative = parts[0].startswith("!")
    names = []
    for p in parts:
        if p.startswith("!") != negative:
            return "ERROR: mixes allowed and ! names, the driver refuses to connect"
        name = p[1:] if negative else p
        if name not in METHODS or name in names:
            return "ERROR: unknown or repeated name " + repr(name) + ", the driver refuses to connect"
        names.append(name)
    if not negative:
        return "OK: positive list " + ", ".join(names)
    if set(names) == METHODS:
        return "BAD: blocks every method, fails open on 42.7.11 to 42.7.13"
    return "OK, but a positive list is clearer: blocks " + ", ".join(names)

service_values = {
    "invoice-api": "scram-sha-256",
    "reports": ",",
    "pdf-store": "!password,!md5,!gss,!sspi,!scram-sha-256,!none",
    "billing": "scram-sha-256,!password",
    "exports": "!password, !md5",
    "search": "SCRAM-SHA-256",
}
for service, value in service_values.items():
    print(service, "->", check_require_auth(value))

On these sample values it prints six lines. It flags reports and pdf-store as BAD, because both fail open on 42.7.11 to 42.7.13. The billing and search values get ERROR, because the driver already refuses them. It passes invoice-api and suggests a positive list for exports.

We compiled AuthMethod.java from the 42.7.13 tag and ran it on these values. Method names are case-sensitive, so SCRAM-SHA-256 is rejected with SQLState 22023. Only a value made entirely of commas names no method, and an empty string is rejected with the same error. These details are undocumented as of 19 October 2026, so pin your version.

Treat any value written through a short declared length as possibly holding other people's data. The advisory warns that values already stored by an affected version can contain this traffic, and upgrading does not clean them.

Start with the code paths your length audit found. Where you know a value's true length, compare it with the stored length. Any extra bytes at the end are padding and may hold leaked traffic.

In the team's case, about 1 in 2,000 PDF uploads (made up) had been cut short. They trimmed those files, told the affected shops and made uploads reject short streams.

Treat the two bugs as case studies in safe configuration and memory reuse. Interviewers care more about the patterns than the CVE numbers.

1. 1

   State each bug in one line

   A rule excluding every method was treated as no rule. Padding reused old send-buffer bytes, which the database stored.

2. 2

   Name the root causes

   One null value meant both unset and nothing allowed. A reused buffer was not wiped when it was empty on entry.

3. 3

   Give the design rules

   Contradictory settings fail closed and loudly. Reused buffers are cleared before reuse, whatever state they are in.

4. 4

   Add defence in depth

   Add a second guard that holds if one layer fails. Verify the server with sslmode=verify-full or channel binding, so the requireAuth bug alone cannot hand your password to a fake server.

5. 5

   Close with the response plan

   Upgrade, search configs, fix declared lengths and check data written in the affected window.