How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

352,262

Total vulnerabilities in the database

CVE-2026-49229 — @actual-app / sync-server

Insufficient Session Expiration

Summary

In OpenID multi-user mode, disabling a user only blocks future OpenID login for that identity. Existing Actual session tokens for the disabled user remain valid, so the user can continue calling authenticated server endpoints after an administrator has disabled the account.

Details

The disabled-user check is present during OpenID login finalization. Existing users are only accepted when the matching row has enabled = 1, and a disabled row causes the OpenID grant to fail before a new session token is created.

// packages/sync-server/src/accounts/openid.ts:284-291
const { id: userIdFromDb, display_name: displayName } =
  accountDb.first(
    &#039;SELECT id, display_name FROM users WHERE user_name = ? and enabled = 1&#039;,
    [identity],
  ) || {};

if (userIdFromDb == null) {
  throw new Error(&#039;openid-grant-failed&#039;);
}

The shared session validation path does not perform the same enabled-user check. It accepts any existing token row that has not expired, then returns the session object to every route protected by validateSessionMiddleware.

// packages/sync-server/src/util/validate-user.ts:10-41
export function validateSession(req: Request, res: Response) {
  let { token } = req.body || {};
  if (!token) {
    token = req.headers[&#039;x-actual-token&#039;];
  }

  const session = getSession(token);
  ...
  return session;
}

This means account disablement and session authorization diverge:

OpenID login path: users.enabled must be 1
Existing session path: token exists and is not expired; users.enabled is not checked

The default token expiration setting is never, so this is not just a short race after disablement on default deployments.

// packages/sync-server/src/load-config.js:260-264
token_expiration: {
  doc: &#039;Token expiration time.&#039;,
  format: &#039;tokenExpiration&#039;,
  default: &#039;never&#039;,
  env: &#039;ACTUAL_TOKEN_EXPIRATION&#039;,
},

Admins can change a user's enabled state through the user update route, but that update does not delete the user's existing sessions. After the update, the old token still satisfies validateSession.

// packages/sync-server/src/app-admin.js:91-101
app.patch(&#039;/users&#039;, validateSessionMiddleware, async (req, res) =&gt; {
  if (!isAdmin(res.locals.user_id)) {
    ...
  }

  const { id, userName, role, displayName, enabled } = req.body || {};

// packages/sync-server/src/services/user-service.ts:98-102
getAccountDb().mutate(
  &#039;UPDATE users SET user_name = ?, display_name = ?, enabled = ?, role = ? WHERE id = ?&#039;,
  [userName, displayName, enabled, roleId, userId],
);

Authenticated server features then continue to trust that session. For example, the sync API installs validateSessionMiddleware for the whole router, so a disabled user can keep using any sync operation that their still-valid session and existing file ownership/access allow.

// packages/sync-server/src/app-sync.ts:37-39
const app = express();
app.use(validateSessionMiddleware);
app.use(errorMiddleware);

This is distinct from the previously published cross-user sync authorization issue: the attacker does not need to access another user's file ID. The bypass is that a disabled user's own session remains authorized after account disablement.

PoC

Run an Actual Sync Server in OpenID multi-user mode with @actual-app/sync-server 26.5.0. Use the default token expiration setting, or any setting where the token has not expired yet.
Log in as a non-admin OpenID user and save the returned Actual session token.
As an admin, disable that same user through PATCH /admin/users by sending enabled: false.
Reuse the old token against a protected endpoint.

Example success check:

curl -s https://actual.example.com/account/validate \
  -H &#039;X-Actual-Token: &lt;disabled_user_existing_token&gt;&#039;

Expected result on the affected code path: the request is still treated as authenticated and returns the disabled user's account/session information instead of 401 or 403.

A sync-facing check uses the same session validation primitive:

curl -s https://actual.example.com/sync/list-user-files \
  -H &#039;X-Actual-Token: &lt;disabled_user_existing_token&gt;&#039;

Expected result on the affected code path: the disabled user can still list and operate on budget files that the stale session is otherwise allowed to access.

Impact

A disabled OpenID user can keep post-authentication access until the session row is deleted or expires. With the default token_expiration: never, this can persist indefinitely.

For a disabled basic user, the confirmed impact is continued access to that user's own budgets and any budgets shared with that user, including sensitive financial data and allowed mutations. For a disabled admin user, the impact is broader because the existing token can still satisfy admin role checks; that condition preserves administrative access after the account was disabled.

The missing rule is that session validation should reject disabled users, and disabling or deleting a user should revoke that user's existing sessions.

Published: Jun 22, 2026
Updated: Jun 23, 2026
CVE: CVE-2026-49229
GHSA: GHSA-cq9c-6w48-qmfg
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.3
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

CWEs:

CWE-613

OWASP TOP 10:

A2 - Broken Authentication

Affected Software
References

Software	From	Fixed in
@actual-app / sync-server	-	26.6.0

https://github.com/actualbudget/actual/security/advisories/GHSA-cq9c-6w48-qmfg

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.