Security · SourceHut

SourceHut's closed registration was closed in the page, not in the handler

meta.sr.ht before 0.89.0 still accepted POST /register/step2 on instances whose operator had disabled registration: the handler returned the closed message on every error path but did not check the setting on the success path, and a CSRF token lifted from /login made the request work. Email confirmation still applied where SMTP was configured. NVD scores it 5.3 Medium on its primary CVSS 3.1 metric and fixes 0.89.0, and nothing collected shows exploitation.

By BoneThursday 5 November 20262 min readSecurity

entryread only

filedThursday 5 November 2026

length2 min

sectionSecurity

subjectSourceHut

sourceson the page

NVD’s record for CVE-2026-121728 states the bug compactly: “SourceHut meta.sr.ht 0.56.11 before 0.89.0 contains an authorization bypass vulnerability that allows unauthenticated attackers to register accounts when public registration is disabled.” It goes on to name the path, “which invokes the unchecked GraphQL RegisterAccount mutation to create accounts.”

Where the check went missing

The researcher’s write-up traces it to a refactor rather than a decision. “Back in 2021, while moving registration code from the frontend to the graphql backend, a subtle logic bug got introduced.” The page said registration was closed, and “the form handler is still there.” Then the sentence that carries the story: “It correctly states that registration is closed on every error path, but on the happy path it does not seem to ever check it.”

That is the shape of the bug. The setting was honoured everywhere except the one path that succeeds, which is the path that matters.

What it takes to use it

“You just need to POST /register/step2 with your desired username, email and password.” The write-up adds the conditions: the instance has registration disabled but “has its SMTP configured properly (you still need to do email confirmation)”, and the request needs a CSRF token. Since no registration form is served, there is no token on the page, but “the token from /login works just fine.”

What it is not

The impact is an account on an instance whose operator had closed registration. It is not account takeover, and it is not privilege escalation on accounts that already exist. NVD’s primary CVSS 3.1 metric puts it at 5.3 Medium, with a secondary CVSS 4.0 metric at 6.9, also Medium, both from the CNA, VulnCheck. The researcher describes the finding as less impactful than the account-takeover bug he published earlier.

What to do

The fix is meta.sr.ht 0.89.0. NVD’s references point at two commits and the 0.89.0 tag, and none of those was read here, so this piece does not describe the patch.

If you run an instance that has registration disabled, the write-up’s compromise check is worth an afternoon: look at the account list for users you did not create. Nothing collected says the flaw has been used in the wild.

Sources: the researcher’s write-up and NVD’s record for CVE-2026-121728.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityPwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailerThe researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.

SecurityAlpine's sshd could be logged into without a password, and the upgrade alone does not close itAlpine's advisory of 5 November describes a password authentication bypass in sshd built without PAM on musl: an attacker who can reach the SSH port logs in with a very long password as an account whose password field is *, provided another account on the machine has a $5$ or $6$ hash. Upstream OpenSSH 10.6p2 calls it a critical security workaround and puts the root cause outside sshd. Alpine's fixed packages run from edge 10.6_p2-r0 back to 3.16 9.0_p1-r6, the upgrade is not complete until sshd is restarted, and no CVE had been assigned.