Better Auth and 4 more: 11 CVEs, all already fixed (CVE-2025-71399)

On the evening of August 2, 2026, eleven CVE numbers (the globally shared IDs assigned to security flaws) were registered at once across five pieces of software. The affected projects are Better Auth, which handles login functionality; Vikunja, a task manager you run on your own server; the database ArcadeDB; FreeRDP, the foundation for remote desktop connections; and the admin interface used on home routers running OpenWrt.

The important part is that none of the eleven is a newly discovered flaw. Every one of the vendor advisories was already public, and fixed versions had already shipped. The oldest was patched in November 2025, and even the newest was fixed by mid-July 2026. All that happened here is that already-public advisories finally got numbers attached.

There are still two reasons to cover this. First, the moment a number is assigned, scanners and alerting systems all react at once, so starting today more people will be asking whether they are affected. Second, one of the eleven is likely still unpatched for a lot of people.

What the 11 entries actually are

All eleven numbers were issued by VulnCheck, a US vulnerability intelligence company. CVE numbers cannot be handed out by just anyone; only authorized organizations, known as CNAs, can assign them. VulnCheck is one of those, and its main role is picking up cases where a vendor published an advisory but never requested a number.

Sorting the eleven by when the advisory came out and when the fix shipped makes the picture clear.

In other words, for 10 of the 11, you need to do nothing if you are on the latest version. The remaining one is FreeRDP. That flaw was not fully fixed in 3.29.0, released July 14; you need 3.30.0, which came out two days later. Anyone who considered their July update done at 3.29.0 is still exposed. We covered the details in our write-up of the FreeRDP vulnerabilities.

The day a number is assigned is not the day the risk began

All eleven had already been published by their vendors on GitHub advisory pages. And every one of them showed "no CVE" at the time of publication. The three Better Auth advisories sat with an empty CVE field for eight months.

This is not unusual. Many open source teams skip the paperwork of requesting a number and simply ship a fix and publish an advisory page. From a purely technical standpoint, that is enough. But most scanners, vulnerability databases, and internal asset inventories match records using the CVE number as the key. Without a number, the issue is invisible to them.

Two practical conclusions follow.

First, there is almost no reason to be alarmed by today's alerts. The numbers arrived today, but the risk has existed since last November or this July, and fixes were available at that point. If your installed version is current, this is already over. Treating it as a brand-new vulnerability and kicking off an emergency response is spending effort in the wrong place.

Second, and this matters more: advisories without a number never show up in alerts at all. In FreeRDP's case, the two issues that did not get numbers were more serious than the two that did. One of the advisories published on July 26 describes a case where, if you run FreeRDP as the receiving end of a remote session, an attacker can pass authentication with no password at all. As of August 2, that one still has no CVE number. If your process waits for numbers before acting, cases like this are never caught.

We also looked at how flaws in bundled software components cascade downstream regardless of whether they have numbers, in our piece on open source dependency risk.

Who would exploit this, and what they get

Nine of the eleven cannot be attacked by just anyone from the outside. The risk comes from people who already have some legitimate way in: ordinary registered users of the service, or a business partner who was handed a share link. If the service allows free signup, an attacker simply creates an account and is now in that position.

What those people can do with these flaws is reach into areas they were never supposed to access, without ever faking their identity. They log in legitimately and then poke at the places where the "this far and no further" boundary is not actually enforced. That means issuing access keys belonging to other people, reading other users' schedules, or promoting themselves to administrator. The awkward part is that the trace left behind looks like a normal login record, so it is hard to spot after the fact.

The people hurt first are the service's own users. Tasks and customer records that were meant to be private end up in someone else's hands, and access keys they never requested get issued under their name. For the operator, a single share link given to an outside collaborator can become the entry point to all internal data, which means the access control design itself needs a second look. Below is what each product's flaws actually do.

Three in Better Auth, the library that handles your logins

Better Auth is a component developers drop into a web service to add login functionality. Email and password sign-in, Google and other third-party sign-in, passkeys, two-factor authentication: it gives developers all of that without building it from scratch. Measured downloads on the package registry run at roughly 6.59 million per week, and it has more than 29,000 GitHub stars. GitHub alone tracks over 15,000 projects that depend on it.

Two big things happened in the past year. In September 2025, Auth.js (formerly NextAuth.js) merged into Better Auth, ending its long run as the default auth library in the Next.js world, and the Auth.js site now strongly recommends Better Auth. Then on July 7, 2026, Vercel acquired Better Auth. So these three numbers landed on the auth library with the most momentum behind it right now.

CVE-2025-71399: one extra slash turns off rate limiting

The most serious of the three, CVE-2025-71399 (8.6 out of 10), lets a defense be switched off by how you write a URL.

Web services normally limit how many times you can hammer a login form. Better Auth ships with a strict default on the login endpoint /sign-in/email: three attempts per 10 seconds. But call the same place as //sign-in/email, with one extra slash, and things change.

When Better Auth decides which requests get the strict limit, it does a plain text comparison to see whether the path starts with "/sign-in". A path with an extra slash does not match, so it slips past the strict limit and falls back to the global default of 100 requests per 60 seconds. The counters that track attempts are also kept per path, so the count starts over. Meanwhile, the component that decides which handler actually runs ignores the duplicated slash and routes the request to the same login handler. The guard at the door sees a different person; the usher sees the same one. That mismatch is the flaw.

The same logic bypasses endpoints a developer deliberately closed off (via a setting called disabledPaths). The vendor advisory lists the impact as those two things, bypassing supposedly closed endpoints and bypassing rate limits, and stops short of describing concrete password brute-force outcomes. The advisory also states explicitly that if you deploy on Vercel with Next.js, or have URL normalization enabled on Cloudflare, the extra slash is cleaned up upstream and you are not affected.

Why a fix from six months earlier never arrived

The interesting part is that the root cause was not in Better Auth's own code but in rou3, a small library used inside it. When rou3 split a path on "/", it discarded every empty segment. Splitting //sign-in/email produces an empty segment, and throwing it away leaves a result identical to /sign-in/email.

This behavior had already been fixed on June 16, 2025. The pull request said only that intermediate empty segments should be preserved, and it was merged as-is four minutes after submission. Nobody treated it as a security issue; it was an ordinary bug fix.

The problem was delivery. Better Auth reaches rou3 through an intermediate library called better-call, and better-call pinned rou3 to "the newest release in the 0.5 line." Written that way, it would never automatically move up to 0.7, where the fix lived. The result: a fix made in June did not reach downstream Better Auth until December 2, 2025, half a year later. Throughout that period, rou3 kept being downloaded roughly 29 million times a week.

When a dependency of a dependency carries a version ceiling, an upstream fix never reaches downstream. Even if the software you use directly is fully up to date, an old component may be pinned inside it.

CVE-2025-71400: deleting other people's passkeys

CVE-2025-71400 (7.1) concerns the add-on that handles passkeys, the password-free login method. The passkey deletion routine looked only at the ID it was given and never checked whether it belonged to the person making the request. Anyone who is logged in can delete someone else's passkey by specifying its ID.

Depending on configuration those IDs are numbered sequentially, 1, 2, 3, and so on, which is why the vendor advisory notes it becomes trivial to walk the IDs and wipe out every passkey. No data is stolen, but users suddenly cannot log in. The fix was four lines, adding a single condition checking whether the passkey belongs to the requester.

There is a caveat here. Passkey support was only split out into a separate plugin in version 1.4; before that it was built into the core. The advisory lists only the post-split plugin as affected. Checking the 1.3.x core code for this article, the deletion routine there was missing the same ownership check. If you are still running 1.3.x or earlier, you will not find yourself anywhere in the published affected range.

CVE-2025-71401: the first request after startup can take the site down

CVE-2025-71401 (5.9) applies when the service URL is not written in the config file: the very first request after the server starts is what fixes that URL. If an attacker gets that first request in, every login-related endpoint afterward returns "not found" and nobody can log in.

The conditions are narrow, and setting the URL explicitly, or simply using a common hosting provider, prevents it. The vendor itself rated the severity "Low." The score assigned this time diverges sharply depending on the scoring method, as covered below.

So which version should you be on?

The latest release is 1.6.25. Get there and none of the three apply. If you are staying on 1.4.x, the newest in that line is 1.4.22.

One correction is needed. The fixed version recorded for CVE-2025-71399 as "1.4.4" is actually 1.4.5. The vendor advisory clearly states the affected range as "below 1.4.5" and the fix as 1.4.5. Tracing the dependencies confirms it: 1.4.4 still pulls in the unfixed rou3, and the switch to the fixed rou3 happens in 1.4.5. The CVE record itself is inconsistent, saying 1.4.4 in the summary and 1.4.5 in the body. Stopping at 1.4.4 leaves you unfixed.

If you are stuck on 1.4.x, though, these three are not what should worry you most. CVE-2026-67336 (8.7), registered on August 1, covers a default setting in third-party sign-in that accepted unsigned tokens; the fix is 1.6.11. The 1.4 line is in scope for that one. Rather than working through numbers oldest-first, look at which flaws are still present in the version you are actually running.

Better Auth has plenty of Japanese-language implementation guides; the Zenn tag alone has 69 articles. Yet we could not find a single Japanese article or advisory covering these three, across JVN iPedia, JPCERT/CC, and domestic media. Information on how to build with it is available in Japanese, while information about the risks only circulates in English. For other examples of flaws in authentication infrastructure, see our pieces on authentik and Casdoor.

Two in Vikunja, the self-hosted task manager

Vikunja gives you Todoist- or Asana-style task management running on your own server. Its pitch is task management you own, free to use with no limits on users or projects. Its container image has been pulled about 9.25 million times, and it has roughly 5,000 GitHub stars. Among people who self-host, it is a well-known option.

CVE-2026-68581: create four share links and become someone else

CVE-2026-68581 (8.1) is among the nastiest of the eleven.

Vikunja has a share link feature. You generate a URL for a project so people without a Vikunja account can see its contents, and it is on by default. The problem was that share links and user accounts each had their own separate sequential IDs, numbered 1, 2, 3 and so on.

The code managing access keys (API tokens) pulled "who is making this request" out of the credentials by taking the ID without checking what type of entity it belonged to. Arrive via share link number 7, and the system reads that as user number 7. Two separate ID sequences were being treated as one.

The attack is startlingly simple. Look up the target's user ID, then create a share link on one of your own projects. If the ID you get is lower than the target's, create another. IDs increment by one each time, so eventually you land exactly on the target's number. In the vendor's own test, four attempts were enough to hit the target ID. Nothing is forged: you use a genuine share link the server legitimately issued.

Once the IDs line up, you can list the target's access keys, issue new keys with whatever permissions you choose, and delete the existing ones. The keys you issue run with the target's permissions, giving you direct reach into private project contents. The fix replaced the ID extraction with a check that the requester really is a genuine user account before reading the ID at all.

CVE-2026-68582: share links expose other people's boards

CVE-2026-68582 (6.5) is a missing permission check in the task listing code, which lets anyone holding a share link read the structure of unrelated users' kanban boards and their user information. It affects 0.24.0 and later, and is also fixed in 2.4.0.

Worth knowing: 2.4.0 bundled ten security fixes. The two that got numbers here are only part of it. The same release also covers marking other people's tasks complete, moving other people's projects elsewhere, account takeover through third-party login email addresses, and password reset links stored in plain text. The vendor explained that permission checks around kanban boards and project hierarchies had not been as strict as elsewhere in the code. If you are below 2.4.0, update regardless of CVE numbers.

An AI-facing connector let every permission check pass

ArcadeDB is a database that handles tabular, graph, and document formats in one system. It was started by the founder of the OrientDB database as its successor. With about 1,058 GitHub stars and roughly 246,000 container image pulls, it is a smaller project than the previous two. Even so, two of its three flaws illustrate problems that can happen in any product.

CVE-2026-68578: it authenticated you, then told nobody

ArcadeDB added MCP support in 26.3.1, released March 4, 2026. MCP is a common connection standard that lets AI assistants operate external software. With it, an AI can query the database directly or modify data in it.

CVE-2026-68578 (7.5) is a flaw in that connector. It is easy to misread, but authentication itself was happening. Token-based identity verification worked. What was missing came next: according to the vendor's explanation, the verified user's identity was never passed along to the database engine.

ArcadeDB's permission checks are built so that when no user is set, they do nothing. That is by design, but here the request proceeded with no user ever set, so every permission check simply passed. It is like checking someone's ID at the front desk, telling none of the guards inside the building, and having each guard conclude nobody has arrived and wave them through. The upshot was that a low-privilege user coming in over MCP could write data, change the schema, and modify permission settings at will. Under the right conditions they could also run arbitrary code inside the database.

The connector is disabled by default and an administrator has to turn it on explicitly. Even so, the pattern to take away is that adding a new AI integration endpoint and forgetting to wire it into existing permission checks keeps happening. We have covered the same kind of case before with Terraform's integration tool, the integration tool for the monitoring platform Grafana, and mcp-pinot. Part of the background is that the MCP specification itself says implementing authorization is optional.

CVE-2026-67356: schema permissions alone are enough to create an admin account

The highest-scoring of the three, CVE-2026-67356 (8.8), involves triggers, small programs that run automatically in response to database activity. From inside a trigger, code had unrestricted reach to the database engine's own control objects.

As a result, someone whose only permission is to change table schemas could create a single trigger and create a brand-new server-wide administrator account. The person you hired to tidy up your data could quietly walk off with the whole keyring. The fix requires a separate permission-management privilege to create script-based triggers.

CVE-2026-67357: masking based on nothing but the word "password"

CVE-2026-67357 (7.5) is a weak check in the feature that displays configuration values, deciding which fields to mask. The check was simply whether the field name contained the string "password." So the shared secret used for server-to-server communication was displayed in the clear, because its name did not contain "password."

That secret can be used, with a specific parameter, to act as the top-level administrator. A read-only user who obtains it can take complete control of the server. That said, if the administrator never actually configured the secret, all that shows is an empty value and there is no real harm. All three are fixed in 26.7.3.

The remaining three: remote desktop software and home routers

The two FreeRDP entries, CVE-2026-68579 (9.6) and CVE-2026-68580 (7.5), carry the highest scores of the eleven and are the only ones likely still unpatched for a lot of people. If you did your July update at 3.29.0, the first of the two is still unfixed. The 9.6 issue triggers when you paste a file from the remote machine locally; the 7.5 one triggers when microphone forwarding is enabled. We covered the remediation details, plus two more serious issues that have no numbers, in our FreeRDP write-up.

The eleventh, CVE-2026-68583 (5.4), concerns an ad-blocking add-on for the OpenWrt admin interface used on home routers. Plant crafted code in the name field of a blocklist entry, and it runs in the administrator's browser the moment they open the status page. It is a way for a low-privilege user to target an administrator, and the fix is 1.2.4-4. This is not about the router itself; it only applies if you installed the add-on and have created multiple users in the admin interface.

One flaw, two scores. Which one should you trust?

Vulnerability severity gets converted into a number out of 10 using a system called CVSS. The older version 3.1 and the newer version 4.0 are both in use right now, and all eleven of these carry both. In some cases the two diverge badly.

The top two are cases the vendor rated Low, or where the impact is only that information becomes visible, yet the new scoring method gives them a 9.3, in critical territory. Look at the breakdown and you find that two completely different flaws were fed word-for-word identical scoring inputs. Those inputs say "no privileges required, severe impact on confidentiality, integrity, and availability" — but CVE-2025-71401, in both its description and its old-method rating, amounts to the service going down, with no mention of data being exposed or altered. CVE-2026-68582 is the same story: under the old method it requires privileges and only exposes information.

As of 10 p.m. on August 2, all eleven sit in the "received, not yet analyzed" state in the US National Institute of Standards and Technology's database. Every score here was assigned by VulnCheck itself, with no third-party verification yet. The numbers may well change during later analysis.

The practical takeaway is simple: do not set priorities on the score alone. Here, reading the conditions, the 6.5 Vikunja flaw and the 7.5 ArcadeDB flaw are more dangerous in practice than the two rated 9.3. What matters is what an attack requires and what it achieves, and the vendor advisory always spells that out. We checked the US CISA catalog of vulnerabilities under active attack (the July 29 edition, with 1,656 entries), and none of these eleven appear there, nor have we found any reports of exploitation.

The bottom line

The eleven CVE numbers registered on August 2 were all retroactive labels on already-published advisories. The fixes came out between November 2025 and July 2026. If you are on the latest version, ten of them require nothing from you.

The to-do list: Better Auth to 1.6.11 or higher (which covers not just these three but the separate issue registered on August 1). Vikunja to 2.4.0. ArcadeDB to 26.7.3. And for FreeRDP, 3.29.0 is not enough; go to 3.30.0. That last one is the only case here that many people probably have not addressed yet.

The thing most worth remembering is that a CVE number is not a signal that a risk has appeared. Numbers can arrive long after a risk has been disclosed and fixed. And some advisories never get a number at all. The most serious FreeRDP issue, the authentication bypass, still has none. Waiting for numbers means moving slowly and missing entire categories of issues outright. Going straight to the advisory pages of the software you run is both more reliable and faster.

Sources

• ▸ GHSA-x732-6j76-qmhm - Double-Slash Path Normalization in rou3 Can Bypass Better Auth disabledPaths config and Rate Limits (December 16, 2025)
• ▸ GHSA-4vcf-q4xf-f48m - Passkey deletion IDOR (November 25, 2025)
• ▸ GHSA-569q-mpph-wgww - External request basePath modification DoS (November 27, 2025)
• ▸ h3js/rou3 - fix: preserve empty segments (#160) (June 16, 2025)
• ▸ Vercel - Vercel acquires Better Auth (July 7, 2026)
• ▸ GHSA-vvcv-vpph-h844 - Link-share principal ID collision allows cross-account API token issuance and management (July 19, 2026)
• ▸ GHSA-rj9j-8772-4h6c - Broken object level authorization in the task-collection endpoint
• ▸ Vikunja - 2.4.0: Ten security fixes, Vikunja Pro, and a new v2 API (July 19, 2026)
• ▸ ArcadeDB - Release 26.7.3 (July 17, 2026)
• ▸ GHSA-6x73-v3rc-f57c - MCP transport does not bind the authenticated principal (July 17, 2026)
• ▸ GHSA-38pf-6hp2-pxww - Privilege escalation via JavaScript trigger (July 17, 2026)
• ▸ GHSA-p9wc-4fhr-78wm - clusterToken disclosed in cleartext via get_server_settings (July 17, 2026)
• ▸ GHSA-q335-4c83-c88h - luci-app-adblock-fast stored XSS
• ▸ GHSA-m37j-jcr2-8gcc - Windows clipboard CliprdrStream_Read heap overflow (July 20, 2026)
• ▸ NVD - CVE-2025-71399
• ▸ NVD - CVE-2026-68581
• ▸ VulnCheck - Advisories