Exposed backoffice on VPS: the overlooked attack surfaces

The typical reaction to a "post-auth" security patch is to conclude that unauthenticated users are protected. That is correct — and insufficient. What these CVEs reveal is that the login interface itself is a permanent attack surface: anyone able to reach the login page can attempt brute force, exploit a session leak, or passively monitor HTTP headers to fingerprint the software version.

On a typical self-hosted VPS, the backoffice is exposed on port 443 of a dedicated public IPv4, with no intermediate network layer. Application authentication manages access, but it does not reduce the attack surface — it filters it after the fact. Four CVEs published in August 2026 illustrate this gap between the perceived and actual exposure.

Authentik up to version 2026.5.6 has a flaw in its SCIM ingestion function. An attacker with a limited-scope SCIM provisioning token can provision a SCIM user whose username matches an existing local account, including a superuser, without validating scope boundaries.

The concrete impact: overwriting or deleting administrator account credentials, with full privilege escalation. What makes this vector particularly dangerous on a VPS: the SCIM endpoint is active as soon as a SCIM source is configured, and it responds on the same domain as the admin interface. Without IP or network restriction upstream, any HTTP client can query it with a compromised token.

CVSS: 8.8 (HIGH). Update to a patched version.

Before version 3.1.3, Flowise allowed authenticated users to set arbitrary TypeORM options via the additionalConfig field in memory and agent nodes. TypeORM options entities, subscribers, and migrations can load local JavaScript files — allowing an attacker with interface access to upload a JavaScript payload and reference it from additionalConfig.entities to execute arbitrary code server-side.

The actual surface is the node configuration interface, accessible to any authenticated user. On a VPS deployment exposed without an authentication proxy, one compromised account is enough to turn Flowise into a remote execution vector.

CVSS: 9.0 (CRITICAL). Update to 3.1.3 or later.

The getLeadIdsByFieldValueAction function in Mautic's AJAX controller reads a field parameter from the HTTP request. Doctrine cannot parameterize column identifiers, and the sanitizer in place does not block spaces, parentheses, or other SQL-relevant characters: an authenticated attacker can inject SQL via the field name itself.

What distinguishes this vector from classic SQL injections: the action requires only a valid session, with no additional permission check. On an exposed Mautic deployment, any low-privilege account — including a forgotten test or demo account — is sufficient to trigger exploitation.

CVSS: 7.1 (HIGH). Apply the Mautic patch released in August 2026.

Apache Airflow from 3.0.0 to 3.3.0 reconstructs serialized exception nodes by dynamically importing a class name extracted from the serialized blob, with no useful restriction on what can be imported. An operator's executor_config can reach this path, allowing a DAG author to force an arbitrary callable to load and execute.

The scheduler triggers this code during normal reconstruction of serialized DAGs. The API server hits it on authenticated reads such as a DAG detail request. On an Airflow instance exposed without an authentication proxy, a compromised DAG author account — or a malicious imported DAG — leads to server-side code execution.

CVSS: HIGH. Update to 3.3.1, which limits the imported class to subclasses of BaseException.

These four CVEs illustrate five distinct patterns found in the majority of self-hosted tools exposed on VPS.

Most exploitations of these surfaces follow a three-phase sequence, easily reproducible on an exposed VPS without network protection.

First phase: passive reconnaissance. The attacker identifies the technology and version via HTTP headers, login page HTML, or health/version endpoints that are often active without authentication. No authentication attempt is needed at this stage.

Second phase: initial access. Brute force against a low-privilege account, credential reuse from a third-party breach, or exploitation of an integration token configured with excessive rights. This phase directly benefits from the public exposure of the login panel.

Third phase: post-auth exploitation. Once a valid account is obtained, the applicable CVE is exploited to escalate privileges, execute code, or exfiltrate data. The outcome varies by tool: full superadmin account takeover (Authentik), server-side code execution (Flowise, Airflow), or arbitrary database read (Mautic).

Network protection is the first line of defense and the only one that is independent of the application itself. It consists of limiting who can physically reach the service, before any application logic.

On a VPS, available tools are the system firewall (ufw allow from <IP> to any port 443), provider security groups, and an access VPN such as WireGuard or Headscale. This layer reduces the attack surface even for future unpublished CVEs: an attacker who cannot reach the login page cannot exploit a post-auth vulnerability.

For services that must remain accessible to distributed teams, a zero-trust access VPN or a fixed egress IP list (corporate proxies) is a better alternative to direct public exposure.

A network authentication proxy such as Authentik or Authelia sits between the Internet and the protected service. Every request must pass through a valid proxy-level session before reaching the application. This layer is independent of application authentication: even if the application has a post-auth vulnerability, the attacker must first bypass the proxy layer.

The concrete mechanism is forward auth: the reverse proxy (nginx, Caddy, Traefik) queries the authentication proxy on each request. If the session is invalid, the request is redirected to the proxy login page, without the protected application ever being contacted. Secondary API endpoints (SCIM, webhooks) benefit from the same protection, since filtering occurs at the reverse proxy level, before routing to the service.

This architecture is compatible with the typical Docker deployment on VPS: the internal Docker network carries communication between the authentication proxy, reverse proxy, and protected services. Only the reverse proxy is exposed on port 443.

The first two layers reduce the attack surface; they do not eliminate it. Monitoring completes the defense-in-depth strategy: it allows detection of an ongoing exploitation or a compromised account before the impact spreads.

For a self-hosted VPS, signals to watch for include: burst authentication failures on the authentication proxy (brute force indicator), accesses to unusual secondary endpoints (SCIM, internal API) from new IPs, administrator account creation or modification, and unusual child processes spawned by the service (code execution indicator).

These signals are collectable with tools already available in the self-hosted ecosystem: application logs centralized in Loki or Graylog, system metrics with Prometheus and Alertmanager, and a tool like Crowdsec that analyzes logs in real time and can automatically block suspicious IPs. The goal is not exhaustive surveillance, but anomaly detection on the most exposed surfaces.

The priority depends on your current deployment state. If services are today exposed directly on the Internet without network restriction, the first action is to enable the system firewall and restrict access to administration ports to your trusted IPs — this takes less than ten minutes and immediately reduces the attack surface, regardless of any CVE.

The second step is deploying an authentication proxy. Authentik installs via Docker Compose and can be configured for forward auth with nginx in a few hours. Once in place, it protects all services behind it, including those whose vulnerabilities are not yet known.

Finally, monitoring must be planned from the start of deployment, not after an incident. Centralized application logs and an alert rule on burst authentication failures are a minimal baseline that requires no complex tooling. These four August 2026 CVEs share a common pattern: their impact would have been far more limited if the login panel itself had not been accessible without restriction from the Internet.