Security · Homepage

Homepage v2.6.0 fixes a pre-authentication bypass in its built-in login

A high-severity advisory says an unauthenticated attacker could reach the dashboard, the service and bookmark APIs and the widget proxy on Homepage 2.0.0 through 2.5.0 by supplying a Next.js internal header; 2.6.0 fixes it, and a reverse-proxy rule is the stopgap while you update.

By BoneSaturday 17 October 20262 min readSecurity

entryread only

filedSaturday 17 October 2026

length2 min

sectionSecurity

subjectHomepage

sourceson the page

Homepage v2.6.0, released today, resolves GHSA-qxcr-4rv3-v23r, a high-severity authentication bypass that affects the self-hosted dashboard’s 2.0.0 through 2.5.0 releases in the official Docker image. Homepage is a popular customizable startpage for home labs, wired into Docker and service APIs. The advisory has no CVE assigned yet, its report has been sanitized for publication, and the fixing release and the advisory were published minutes apart.

The bypass

The advisory’s summary, in its own words: when Homepage’s built-in authentication is enabled (HOMEPAGE_AUTH_ENABLED=true), an unauthenticated attacker can bypass the login check on protected pages and API routes, using a Next.js internal request header combined with a build-time key that ships across the same image tag. The details: Next.js skips its middleware entirely for internal on-demand revalidation requests, identifying them by a header whose value must match the build’s preview key; the key is generated during the build and stored in the output. Supplying the header with the right value skips the middleware, including the authentication check and HOMEPAGE_ALLOWED_HOSTS validation.

What an attacker gets

Per the advisory, an unauthenticated network attacker who can reach the instance can view the dashboard and the /api/services and /api/bookmarks responses; read Kubernetes cluster and pod status, if configured; and use the service widget proxy to make Homepage send requests to configured backends and return their responses. Stored credentials are not returned directly. None of the three requires an account or a session on the instance.

The Homepage dashboard shown on a tablet: a dark glassmorphism layout with system widgets for Proxmox, NAS storage and network traffic, media tiles for Plex and Emby, and tiles for services like Radarr, Sonarr, SABnzbd, Portainer and Nextcloud, over a rainy city wallpaper. — The official Homepage dashboard screenshot, shown on a tablet. It does not depict the vulnerability. Image: Homepage.

The fix and the workaround

The fix is the upgrade: v2.6.0’s notes list “Resolve GHSA-qxcr-4rv3-v23r” in the security section, alongside an authentication architecture refactor and a fix that preserves dollar sequences in environment and file secrets. If an immediate upgrade is not possible: configure the reverse proxy to strip or reject the x-prerender-revalidate request header, and do not expose Homepage directly to untrusted networks without a proxy in front. The advisory describes the built-in authentication path in the official Docker image; instances without authentication enabled are not the case it covers. The advisory record credits the report to nicholas-fedor and the remediation to maintainer shamoon.

My read

Patch first, read second: a pre-authentication path to the dashboard, its service and bookmark APIs, and the widget proxy is about as exposed as a home-lab service gets, and the fix shipped the same morning the advisory went out. The header-strip rule is worth keeping on a reverse proxy anyway, and the episode is a reminder that a login page is not a perimeter.

Source: the v2.6.0 release and the security advisory.

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.