12 flaws in baserCMS, only one is traceable (CVE-2026-65875)

On July 30, 2026, the developers of baserCMS — a Japanese open-source content management system — published 12 vulnerabilities at once. Three carry the project's own top rating of Critical, and they include issues that let an attacker pull data out of the database and run arbitrary programs on the server. Versions 5.0.0 through 5.2.8 are affected; the fixes are 5.2.10 and 5.3.0, both released the same day.

But the twelve findings are not really the story here. The story is that almost none of them appear in the standard places you would look up a vulnerability.

Vulnerabilities normally get a CVE number, a globally shared identifier. With the number you can pull details from the NVD run by the US government, or from CVE.org which administers the numbering. For these twelve, though, one was never assigned a number at all, and of the eleven that were, ten return "no such record exists" from CVE.org. We queried all eleven individually to confirm. Exactly one is traceable.

On top of that, none of the twelve are in GitHub's global advisory database. That matters concretely: if you run baserCMS in a project with GitHub's automated alerting (Dependabot) switched on, you will not be warned about any of these twelve. The nine published in March 2026 are in there properly, so nothing is structurally broken — this batch specifically is missing.

Meanwhile JVN, Japan's vulnerability portal, carries one of the twelve. As of August 3 we could find no Japanese-language coverage at all. A Japanese CMS, disclosed in Japanese, is almost invisible in the Japanese-speaking world.

All twelve

The full set, first. Severity is the rating the project assigned on GitHub. The "CVE status" column reflects what CVE.org actually returned when we queried each number on August 3.

That breaks down as three Critical, eight High, one Medium. Where the Login column says "Not stated," the advisory does not specify what privileges are needed — that is not the same as saying none are. We are leaving the unknowns unknown.

The affected version range needs a caveat too. The project's official notice says 5.0.0 through 5.2.8, but the twelve GitHub entries disagree among themselves: "5.2.8," "<= 5.2.3," "5.2.x (latest)," and "5.2.2" all appear, presumably reflecting whichever build each reporter tested. For decisions, use the widest of them — the official 5.0.0 through 5.2.8.

Who comes looking, and what it costs

The first thing to arrive at a CMS flaw is a program that reads freshly published advisories and sweeps for sites matching the conditions. When a disclosure names the component and the function, building that sweep is not hard. And baserCMS is easy to fingerprint from outside — the shape of its admin URLs and the filenames in its distributed themes give it away.

What follows a match is either pulling the data out or putting a program in. This batch supplies both: five issues reach the database, and four lead to code execution or file placement on the server. The blog tags API issue, marked as needing no login, is the one with no prerequisites at all — which makes it the likeliest target for automated sweeps.

What gets lost depends on the site. baserCMS ships with contact form functionality and stores submissions in the database. On a corporate site, that means the names, phone numbers, and enquiry text collected through the form. One of the twelve (CVE-2026-62956) sits in exactly that code path. For operators, a program planted on the server turns the site into a relay for fraud redirects and spam, followed by removal from search results and loss of the domain's reputation. Recovery takes days to weeks.

The three rated Critical

Starting with the three the project rated at its highest level.

The one with no CVE number: database access and code execution

Alone among the twelve, this one has no CVE number — only the internal identifier GHSA-cg65-f2m7-9fqj. The flaw is in the database service layer and is described as leading to both unauthorized queries and arbitrary code execution. The project rates it Critical; reported by DhiyaneshGeek.

No number means there is no way to refer to this one in a vulnerability management tool or an asset inventory. Any organisation that reconciles "have we handled the baserCMS issues?" by CVE number will drop this single item every time. One of the most severe findings in the batch sits in the least trackable state.

CVE-2026-62950: blog tags reach the database

In the code handling blog tags, the value used for sort ordering went straight into a database query. This shape of flaw is called SQL injection, and it makes the database run queries the developer never intended. Member records, form submissions, unpublished posts — anything in that site's database is in reach. The project scores it 9.1 out of 10, Critical. Reported by tuannm-1876.（the project's advisory GHSA-h68w-vjc3-82wv）

CVE-2026-59872: the admin API sort parameter does the same

In the admin API, values passed as sort order and filter conditions were used in database queries without validation — the same defect as above, in a different place. Rated Critical; reported by sdrk3nD. Five of the twelve are this same shape of flaw. That points to an inconsistent convention for handling these values rather than a single slip.（the project's advisory GHSA-w8m6-r35w-9xrq）

The remaining nine

CVE-2026-62951: the blog tags API, reachable without logging in

The only one of the twelve explicitly documented as requiring no login. The blog tags API allows database injection through its sort parameter, and the advisory also cites a problem with how authentication is handled. With no preconditions, this is the entry most exposed to automated scanning. Reported by n11-Ryoma.（the project's advisory GHSA-vppr-96xg-c6fh）

CVE-2026-62956: the code handling contact form data

The service handling messages submitted through mail forms allows the same database injection via its sort parameter. On a corporate site, this is where the personal data accumulates. Reported by tuannm-1876.（the project's advisory GHSA-pqpg-933x-f4c5）

CVE-2026-62969: code execution through database restore

Abusing the feature that restores a database from backup allows arbitrary programs to run on the server. Administrator rights are needed, but success means the server itself. Reported by toratako.（the project's advisory GHSA-5hvm-279m-gg7r）

CVE-2026-62954: theme editing can write files anywhere

The theme file API does not validate where it writes. Files can be placed outside their intended location, and if that location executes them, it becomes a takeover. Reported by valmet083.（the project's advisory GHSA-26mh-9qwx-cxvq）

CVE-2026-62955: the March fix did not fully close the hole

In character, this may be the heaviest of the twelve. It documents that the mitigation shipped for CVE-2026-30940 in March 2026 can be bypassed. The way the code resolves a file's real location leaves a gap that walks straight past the March patch. Reported by tuannm-1876 and arpitjain099.（the project's advisory GHSA-2pj4-v76f-wjvx）

For anyone who applied the March update and considered the matter closed, the premise no longer holds. A record saying "patched" can coexist with a hole that was never actually shut.

CVE-2026-62952: arbitrary binaries via the PHP path parameter

The parameter specifying the location of the PHP binary is not validated, so pointing it at something else runs that instead. Reported by smitocaru.（the project's advisory GHSA-vq8m-9cq4-5qh2）

CVE-2026-62953: upload filenames can choose their destination

Upload filenames are not sufficiently sanitised, so directory traversal sequences inside the name place the file somewhere it should not go. Same reporter as the previous item, smitocaru.（the project's advisory GHSA-h26f-xjhf-995v）

CVE-2026-65875: the only one traceable from a public database

The CSV export feature writes submitted values out unmodified. Open the resulting file in a spreadsheet and a leading symbol makes the contents parse as a formula and execute. The target here is not the site's server but the computer of whoever opens the file. Reported by Le Nguyen Anh Quan, Do Ich Nam, and Nguyen Ngoc Minh of VCSLab (Viettel Cyber Security).（the project's advisory GHSA-96gq-h93q-hhq2）

This is the single item that went through JPCERT/CC coordination, published as JVNVU#94952030 and recorded in both CVE.org and the NVD. It is the only one of the twelve you can reach by searching its number. It is also, by severity, not among the top of the batch.

CVE-2026-63012: skipping the admin API's permission check

Across every admin API endpoint, exploiting a fallback in the authentication logic bypasses the authorization check. The project's rating is Medium, the only one in the batch, but the scope — every admin endpoint — is worth noting. Reported by toratako and arpitjain099.（the project's advisory GHSA-wgvx-x5g3-9v29）

Search the numbers and almost nothing comes back

Here is the part that matters. These twelve fall out of nearly every standard channel for tracking vulnerabilities. What we actually found:

A word on how a number can exist while its record does not. CVE numbers can be reserved before publication. These ten are sitting at that reserved stage — the number appears in the project's advisory while the record behind it has not yet been released. They will presumably appear eventually. As of August 3 they cannot be looked up.

The consequence with the widest practical reach, we think, is the zero in GitHub's advisory database. That database is what feeds Dependabot, the automated alert that tells a composer-managed PHP project it is running a dangerous version. For these twelve, that alert does not fire.

We confirmed the mechanism itself is not broken. The nine published in March 2026 are present in the global database. This batch is visible on the project's own GitHub pages but has not been promoted into the wider database — something appears to have stalled partway through the process.

Which means the automated paths to noticing are effectively closed. Noticing requires going to the project's GitHub or website yourself. That is precisely the problem covered in our OSS supply chain scanner: having to go count your own dependencies' risks by hand.

For completeness: as of August 3 none of the twelve appear in CISA's catalog of vulnerabilities confirmed to be under attack. baserCMS has never been listed there, and we found no reports of exploitation.

What to do now

If you run baserCMS 5.x, move to 5.2.10 or 5.3.0. Both shipped on July 30. 5.3.0 is the feature release adding PHP 8.5 and CakePHP 5.2 support; 5.2.10 stays on the 5.2 line and takes only the fixes. If you would rather not change much, 5.2.10 is sufficient.

One thing to watch. All twelve GitHub entries list the fixed version as 5.3.0 and never mention 5.2.10. Anything reading that data mechanically may keep flagging a 5.2.10 install as vulnerable. That 5.2.10 contains the fixes is confirmed by the project's release and its forum announcement.

Test the upgrade more carefully than usual. The project's forum has reports of token validation errors and themes becoming unchangeable after updating. Try it on a copy before touching production.

Also check whether anyone got in already. Four of the twelve allow placing files on the server. An update stops the next intrusion; it does not remove files already placed. Look for administrator accounts you do not recognise, and for unfamiliar .php files under the theme and upload directories.

Finally: baserCMS in 2026 has published in batches — nine in March, twelve in July. The next time this happens, the automated notification may again be unavailable. If you depend on it, build the habit of checking the project's security notices page directly.

Sources

• ・baserCMS — GitHub Security Advisories (primary source for all 12)
• ・baserCMS — security notice, July 30, 2026
• ・baserCMS — security notices index
• ・baserCMS forum — 5.2.10 / 5.3.0 release announcement
• ・JVN — JVNVU#94952030 (the only one of the 12 listed)
• ・JVN iPedia — JVNDB-2026-026396
• ・NVD — CVE-2026-65875 (the only one of the 12 recorded)
• ・CVE.org — CVE-2026-65875
• ・GitHub Advisory Database — basercms (used to confirm coverage stops at the March batch)
• ・baserCMS — releases (5.2.10 / 5.3.0 publication dates)
• ・CISA — Known Exploited Vulnerabilities Catalog