Pake desktop wrapper lets attackers write files anywhere on disk
A path traversal bug in Pake's download_file command (CVSS 8.8) gives attackers a straight line to persistence on macOS, Linux, and Windows. Also: pac4j shipped two broken auth checks, and iFlytek's astron-agent leaks workflows across tenants.
Nothing on fire, but don't sleep on these. Pake has a path traversal bug (CVE-2026-82635, CVSS 8.8) that lets an attacker drop persistent payloads through its download_file command, and two pac4j releases shipped with broken authorization logic. Four patches total, no exploitation in the wild yet.
Today's CVEs
Sorted by urgencyCVE-2026-82635
NVDPake, the tool that wraps web apps into desktop apps via Tauri, doesn't sanitize filenames passed to its download_file command. An attacker who controls the filename can use path traversal (like "../") to write arbitrary content anywhere the current user can write. On macOS that means dropping a LaunchAgent for persistence; on Linux an autostart entry; on Windows a Startup folder shortcut. The result is code execution under your user account.
- Affected estate
- Anyone shipping or running desktop apps built with Pake versions before 3.13.1, on any OS
- How to check
- Check your Pake dependency version in package.json or Cargo.toml. Anything below 3.13.1 is vulnerable.
- Included because
- CVSS 8.8; arbitrary file write; persistence and code execution; affects all Pake-built desktop apps
- Action
- Upgrade Pake to 3.13.1+, rebuild the app, and push an update to end users.
- Why it matters
- An attacker can write arbitrary files outside the Downloads folder, install persistence mechanisms, and gain code execution under the user's account.
Evidence trail
- NVD: View source
CVE-2026-82461
NVDpac4j-oidc before 6.5.6 never actually verifies access token signatures, issuers, audiences, or expiry when it extracts Keycloak roles. An attacker can forge an access token stuffed with admin roles, pair it with a legitimately obtained ID token, and your app will trust those roles. If you rely on pac4j for role-based access control with Keycloak, your authorization checks are effectively bypassed.
- Affected estate
- Java/JVM developers and operators running apps that use pac4j-oidc with Keycloak for role-based authorization
- How to check
- Check your Maven or Gradle dependency tree for pac4j-oidc. Versions below 6.5.6 are vulnerable.
- Included because
- CVSS 8.1; authentication/authorization bypass; forged tokens accepted; common OIDC library
- Action
- Upgrade pac4j-oidc to 6.5.6+, redeploy, and review access logs for suspicious role claims.
- Why it matters
- Attackers can forge access tokens with arbitrary roles and bypass your authorization checks entirely.
Evidence trail
- NVD: View source
CVE-2026-82463
NVDpac4j-core before 6.5.6 has the authorization logic in CheckProfileTypeAuthorizer backwards. It approves profiles that should be rejected and rejects ones that should be approved. An attacker can authenticate through a weaker auth client and still access resources that require a stronger profile type. If you use pac4j's profile type checking to enforce step-up or multi-factor gating, it's not working.
- Affected estate
- Java/JVM developers and operators running apps that use pac4j-core's CheckProfileTypeAuthorizer for tiered or step-up authentication
- How to check
- Check your Maven or Gradle dependency tree for pac4j-core. Versions below 6.5.6 are vulnerable. Search your codebase for CheckProfileTypeAuthorizer usage.
- Included because
- CVSS 8.1; authentication bypass; inverted authorization logic; common auth library
- Action
- Upgrade pac4j-core to 6.5.6+, redeploy, and run integration tests confirming that weaker profiles are correctly denied.
- Why it matters
- The reversed logic means your step-up or strong-auth gates are open to anyone with a basic session.
Evidence trail
- NVD: View source
CVE-2026-82475
NVDiFlytek's astron-agent (through 1.1.1) doesn't check workflow ownership on the copyFlow endpoint. Any authenticated user can enumerate workflow IDs and either overwrite another tenant's workflows or copy private ones to read their definitions. This is a multi-tenant isolation failure: one tenant can tamper with or steal another tenant's workflow logic.
- Affected estate
- Teams running iFlytek astron-agent 1.1.1 or earlier in multi-tenant environments
- How to check
- Confirm your astron-agent version. If you're on 1.1.1 or below, the copyFlow endpoint lacks ownership validation.
- Included because
- CVSS 8.1; multi-tenant authorization bypass; authenticated but low-complexity attack
- Action
- Upgrade when a fix is released. In the meantime, block or restrict the copyFlow API endpoint at the reverse proxy or API gateway layer.
- Why it matters
- Authenticated users can overwrite or exfiltrate other tenants' workflows, breaking tenant isolation.
Evidence trail
- NVD: View source
One email, every Wednesday morning.
SubscribeFrom the field notes
From this beat
Read the rest of the field notes →