Skip to main content

Karakeep EUVDEUVD-2026-31826

| CVE-2026-45082 HIGH
Server-Side Request Forgery (SSRF) (CWE-918)
2026-05-26 GitHub_M
7.6
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Register or use existing Karakeep account
  2. Delivery
    Submit bookmark URL pointing to attacker server
  3. Exploit
    Crawler/video worker fetches URL
  4. Install
    Attacker returns 302 to internal Docker service
  5. C2
    Worker dereferences redirect without re-validation
  6. Execute
    Internal service response stored in bookmark metadata
  7. Impact
    Attacker reads exfiltrated data via UI

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK

2 techniques across 2 tactics: Initial Access, Credential Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

The attacker must hold a valid Karakeep account on the target instance (CVSS PR:L) and must be able to submit a URL into either the link crawler or the video download ingestion flow - both default-enabled paths. The attacker must control a web server that returns an HTTP 3xx redirect to an internal hostname or IP. Exploitation is meaningfully limited to deployments where reachable internal services exist on the same Docker network or host network namespace as the Karakeep workers; a single-container deployment with no sibling services on a private network has little to steal. No user interaction is required (UI:N), and exploitation is network-reachable end-to-end (AV:N).

Impact

Signals are mixed and point to a real but bounded priority. CVSS 7.6 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L) reflects network-reachable exploitation by a low-privileged authenticated user with no user interaction and high confidentiality impact - consistent with reading internal service responses. SSVC reports exploitation status 'poc' (publicly available exploit code exists), not automatable, with partial technical impact, and EPSS sits at 0.03% (10th percentile) with no CISA KEV listing - so exploitation is feasible but not yet widespread. The realistic threat model is an attacker who already has (or can self-register) a Karakeep account; for public/multi-tenant deployments this is trivial, while single-user self-hosted installs face a much lower exposure. Note one tension worth verifying: PR:L assumes user accounts exist, but some Karakeep instances allow open signup, effectively reducing this to unauthenticated reachability - operators should confirm their signup configuration.

Exploit ScenarioDerived

An authenticated Karakeep user adds a bookmark pointing at https://attacker.example/redirect, where the attacker's server responds with a 302 to http://meilisearch:7700/indexes or http://172.17.0.1:9200/_cat/indices. The crawler or video downloader follows the redirect into the Docker bridge network, fetches the internal service's response, and stores fragments of it as scraped metadata that the attacker can read back through the normal bookmark UI. Publicly available exploit code exists per SSVC, so weaponization effort is minimal.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 08, 2026

Server-side request forgery in Karakeep self-hosted bookmark manager versions prior to 0.32.0 allows authenticated users to bypass internal-network protections by chaining attacker-controlled HTTP redirects, reaching Docker-internal services from the crawler and video download flows. Publicly available exploit code exists per SSVC, though EPSS is low at 0.03% and the issue is not in CISA KEV. Fixed in version 0.32.0.

RemediationAI

Vendor-released patch: upgrade to Karakeep 0.32.0 or later, which adds redirect-aware SSRF validation; release notes and details are at https://github.com/karakeep-app/karakeep/security/advisories/GHSA-g647-327m-79g9. If immediate upgrade is not possible, restrict who can submit URLs by disabling open registration and auditing existing user accounts, and isolate the Karakeep containers from sensitive sibling services by placing them on a dedicated Docker network with egress restricted to the public internet via an egress proxy that re-validates each redirect hop against RFC1918/Docker-internal ranges - note this breaks legitimate fetching of any internal bookmarks and may slow scraping. As a narrower stopgap, disable the video download workers (KARAKEEP_CRAWLER_VIDEO_DOWNLOAD or equivalent) and accept that videos will not be archived. Do not rely on the application's built-in private-IP filter alone, since that is precisely what is bypassed.

Affected VersionsENISA

karakeep < 0.32.0

Affected Packages

euvd karakeep fix: 0.32.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Karakeep (CPE karakeep-app:karakeep) is a Node.js-based self-hostable bookmark-everything application that fetches user-supplied URLs to scrape page metadata, archive content, and download embedded video. The vulnerability is a classic CWE-918 Server-Side Request Forgery: the application validates the initial URL against an internal/private-IP blocklist but follows HTTP 3xx redirects without re-validating each hop. Because Karakeep is typically deployed in Docker with sibling services (meilisearch, browser, postgres, chrome) on a shared user-defined bridge network, an attacker-controlled origin can return a redirect to a Docker DNS name or RFC1918 address and have the fetcher dereference it. The same redirect handling exists in multiple ingestion paths - the link crawler and the video downloader - multiplying the attack surface.

Know when Karakeep gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.6 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L

Primary rating from Vendor (GitHub_M) · only source for this CVE.

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
Low

Lifecycle Timeline

2
Patch available
May 26, 2026 - 16:02 EUVD
CVE Published
May 26, 2026 - 13:45 nvd
HIGH 7.6

DescriptionCVE.org

Karakeep is a elf-hostable bookmark-everything app. A Server-Side Request Forgery (SSRF) protection bypass vulnerability was identified in versions prior to 0.32.0 affecting redirect-following processing components. Although the application implements protections intended to prevent requests toward internal/private network destinations, these protections could be bypassed through crafted HTTP redirect chains. By leveraging attacker-controlled redirects, an authenticated user could cause vulnerable application components to initiate requests toward internally reachable Docker network services accessible from the application environment. The issue affected multiple processing paths, including crawler-related functionality and video download processing flows. Version 0.32.0 contains a patch.

Executive ViewAI

Why It Matters

Karakeep, a self-hosted bookmark management solution, contains a network security flaw in versions prior to 0.32.0 that allows authenticated users to circumvent network isolation controls and gain unauthorized access to internal Docker-hosted services. The vulnerability directly threatens organizations where user account credentials may be compromised or where insider threats exist, enabling attackers to move laterally across the internal technology infrastructure. Vendor patches are available, and immediate deployment should be a priority.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.0%
Top 90% exploitable
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy