Exploit Database
152,445 exploits tracked across all sources.
Safetica Endpoint Client 10.5.75.0/11.11.4.0 - Protected Process Termination
Kernel driver ProcessMonitorDriver.sys in Safetica's endpoint client x64 , versions 10.5.75.0 and 11.11.4.0, allows unprivileged user to abuse IOCTL path and terminate protected system processes.
by TreasureBoy99
CVSS 7.5
pac4j-jwt <4.5.9/5.7.9/6.3.3 - Auth Bypass
pac4j-jwt versions prior to 4.5.9, 5.7.9, and 6.3.3 contain an authentication bypass vulnerability in JwtAuthenticator when processing encrypted JWTs that allows remote attackers to forge authentication tokens. Attackers who possess the server's RSA public key can create a JWE-wrapped PlainJWT with arbitrary subject and role claims, bypassing signature verification to authenticate as any user including administrators.
by TreasureBoy99
CVSS 9.1
Guzzle: Dot-Only Cookie Domains Match All Hosts in guzzlehttp/guzzle
Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, CookieJar incorrectly accepts cookies with a dot-only Domain attribute and whitespace-padded variants. SetCookie::matchesDomain() removes leading dots from the cookie domain, normalizing dot-only values to the empty string; SetCookie::validate() only rejected a strictly empty domain, so these cookies could be stored and the empty normalized domain was treated as matching any request host. An attacker-controlled origin that an application requests with a shared cookie jar can therefore set a cookie that Guzzle later sends to unrelated hosts using the same jar. This may allow cookie injection or session fixation against downstream services, depending on how those services interpret the injected cookie. This vulnerability is fixed in 7.12.1.
CVSS 5.8
Guzzle: Dot-Only Cookie Domains Match All Hosts in guzzlehttp/guzzle
Guzzle is an extensible PHP HTTP client. Prior to 7.12.1, CookieJar incorrectly accepts cookies with a dot-only Domain attribute and whitespace-padded variants. SetCookie::matchesDomain() removes leading dots from the cookie domain, normalizing dot-only values to the empty string; SetCookie::validate() only rejected a strictly empty domain, so these cookies could be stored and the empty normalized domain was treated as matching any request host. An attacker-controlled origin that an application requests with a shared cookie jar can therefore set a cookie that Guzzle later sends to unrelated hosts using the same jar. This may allow cookie injection or session fixation against downstream services, depending on how those services interpret the injected cookie. This vulnerability is fixed in 7.12.1.
CVSS 5.8
OpenSSL - Client-Side Memory Leak in OCSP Response Checking
Issue summary: A malicious TLS server can cause a memory leak in a TLS
client that has enabled OCSP response checking by sending an OCSP
response that contains no single response entries.
Impact summary: An attacker can leak an attacker-tunable amount of memory
per TLS handshake in a victim client application. A long-running client
that repeatedly connects to a malicious server can have its memory
exhausted, resulting in a Denial of Service.
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Description: The affected function is called during X.509 certificate
chain verification when OCSP response checking is enabled
with the X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL
verification flags, for example when a TLS client verifies an OCSP
response stapled into the TLS handshake by the server.
When the received BasicOCSPResponse contains an empty SEQUENCE OF
SingleResponse, which is permitted on the wire and accepted by the
OpenSSL decoder, the OCSP_BASICRESP structure allocated by
OCSP_response_get1_basic() was not freed because an early return
bypassed the cleanup code at the end of the function.
The amount of memory leaked per handshake can be amplified by the
attacker by padding the certs field of the BasicOCSPResponse with
bogus certificates, which are parsed and stored in the leaked
structure before the empty response check triggers the early return.
A long-running TLS client that repeatedly connects to a malicious
server can have its memory exhausted over time.
OCSP response checking is not enabled by default. Only client
applications that explicitly enable the OCSP response check
verification flags are affected.
FIPS impact: no
The FIPS modules in 4.0 and 3.6 are not affected by this issue as the
affected code is outside the OpenSSL FIPS module boundary.
CVSS 7.5
Electron: window.open features string controls some window options considered privileged
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3, some window options supplied by web content in the window.open() features string were applied to the new BrowserWindow without an allowlist. Untrusted content could set window options it should not control, including options that cause the main process to access attacker-chosen file or network paths, when untrusted content can call window.open() and the app does not override child window options via setWindowOpenHandler or overrideBrowserWindowOptions. This issue is fixed in 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3.
CVSS 5.3
Electron: Sandboxed iframe can bypass the allow-popups restriction via the OpenURL navigation path
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.10, 41.10.3, and 42.0.1, a sandboxed iframe without the allow-popups keyword could still open a new window or trigger setWindowOpenHandler with no user interaction because new-window navigations taking the OpenURL path did not apply the iframe sandbox popup restriction. Apps that embed untrusted content in sandboxed iframes and rely on the absence of allow-popups to prevent window creation are affected, while apps that deny window creation in setWindowOpenHandler or do not embed untrusted content in sandboxed iframes are not affected. This issue is fixed in 39.8.10, 41.10.3, and 42.0.1.
CVSS 7.2
Electron: DevTools JavaScript Injection via Unsanitized Dock State Parameter
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1, the mode option of webContents.openDevTools() was not sanitized before use by the DevTools frontend. If an attacker can influence this value, script under their control may run in the DevTools context, which in unsandboxed configurations has access to Node.js, including when untrusted input reaches the mode argument of openDevTools() or untrusted content calls openDevTools() on a webview it embeds. This issue is fixed in 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1.
CVSS 5.7
Electron: contextBridge object copy honors prototype setters
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4, objects copied across the contextBridge boundary from untrusted content could carry an attacker-influenced prototype, enabling prototype-pollution-style attacks against preload code despite context isolation being enabled. Apps are only affected if their preload code accepts object arguments from untrusted content and reads properties from them without own-property checks, while apps that only accept primitive arguments or validate object arguments are not affected. This issue is fixed in 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4.
CVSS 5.4
Electron: DevTools embedder handler executes arbitrary files via shell open
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3, the DevTools reveal in file manager action could launch the target file rather than reveal it. An attacker with a separate means of running script inside the DevTools frontend, such as a malicious DevTools extension, could use showItemInFolder handling to execute native code outside the sandbox when DevTools is opened for windows exposed to untrusted content or untrusted DevTools extensions. This issue is fixed in 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3.
CVSS 6.9
dr_wav.h W64 CUE Chunk Metadata Parsing Integer Overflow Leading to Heap Buffer Overflow on 32-bit Builds
dr_libs dr_wav.h (all versions through current master) contains an integer overflow in W64 CUE chunk metadata parsing. In drwav__metadata_process_chunk(), a stage-1 capacity estimate truncates the 64-bit W64 chunk sizeInBytes to size_t before dividing by DRWAV_CUE_POINT_BYTES; on 32-bit builds this truncation causes the pre-allocated extra metadata capacity to be computed incorrectly. The subsequent read in drwav__read_cue_to_metadata_obj() computes the actual cue point count and allocation size using the full-precision, attacker-controlled cuePointCount field without cross-checking it against the stage-1 capacity estimate, and the only bounds enforcement on the resulting memory region (drwav__metadata_get_memory()) is a DRWAV_ASSERT, which compiles to a no-op under -DNDEBUG (the default for release builds). A crafted W64 WAV file can therefore cause a heap buffer overflow in any 32-bit application parsing untrusted WAV metadata.
CVSS 7.8
FreeModbus LINUXTCP Port Off-by-One Global Buffer Overflow in xMBPortTCPPool()
The LINUXTCP port of FreeModbus contains an off-by-one bounds check in xMBPortTCPPool() (demo/LINUXTCP/port/porttcp.c). The check `if (usTCPFrameBytesLeft > MB_TCP_BUF_SIZE)` uses a strict greater-than comparison instead of greater-than-or-equal against the 263-byte MB_TCP_BUF_SIZE limit. An MBAP frame with a Length field of 264 makes usTCPFrameBytesLeft equal to 263, which passes the flawed check, and the subsequent recv() call writes up to 263 bytes starting at buffer offset 7 into the 263-byte static buffer aucTCPBuf, overflowing it by 7 bytes into the adjacent static variable usTCPBufPos. A single crafted, unauthenticated Modbus TCP packet triggers the overflow, since Modbus has no built-in authentication.
CVSS 9.1
tinyobjloader-c Stack Buffer Overflow in MTL Material File Line Parsing
tinyobjloader-c's tinyobj_parse_and_index_mtl_file() (tinyobj_loader_c.h) reads each line of a .mtl material file into a fixed 4096-byte stack buffer `linebuf` via memcpy(linebuf, p, p_len), guarded only by `assert(p_len < 4095)`. Because assert() compiles to a no-op under -DNDEBUG (standard for release builds), a crafted .mtl file containing a line (e.g. a "newmtl" material name) longer than 4096 bytes overflows linebuf into the adjacent stack variable namebuf and beyond, corrupting the stack of any application that loads attacker-supplied 3D model/material files. The identical vulnerable pattern is duplicated in a second function in the same file.
CVSS 7.8
microtar Stack Buffer Overflow in mtar_write_file_header() and mtar_write_dir_header()
microtar's mtar_write_file_header() and mtar_write_dir_header() functions (src/microtar.c) copy a caller-supplied entry name into the 100-byte `name` field of a stack-allocated mtar_header_t via strcpy(h.name, name), with no check that strlen(name) is less than 100 before the copy. Any application that calls these functions with an externally-influenced filename longer than 99 characters (e.g. when archiving user-supplied or attacker-controlled filenames) triggers a stack buffer overflow.
CVSS 9.8
rust-iot-platform Authentication Bypass via Non-Validated Authorization Header
rust-iot-platform's AuthToken request-guard implementation (api/src/main.rs) only checks whether the Authorization HTTP header is present, and never validates its value against any session, token store, or signature. Any request carrying an arbitrary non-empty Authorization header (e.g. `Authorization: fake`) satisfies the guard, granting access to every endpoint protected only by this request guard.
CVSS 9.1
ember-dynamic-render-template Client-Side Template Injection via Unsanitized templateString
The render-template component of ember-dynamic-render-template (addon/components/render-template.js) passes its `templateString` property directly into Ember/Glimmer's compileTemplate() (from @ember/template-compilation) with no sanitization, allow-listing, or validation of the input. Because compileTemplate() dynamically compiles and renders the supplied string as a live Handlebars/Glimmer template, any application that renders attacker-influenced data through this component's templateString property is exposed to client-side template injection: an attacker-controlled Handlebars expression is compiled and executed in the context of the rendering component, which can be leveraged for cross-site scripting depending on what helpers/context are exposed to the compiled template.
CVSS 6.1
SirenGPS Android Application 2.19.44 - Authenticated Incorrect Access Control via User Identifier Parameter Manipulation
SirenGPS Android Application 2.19.44 is vulnerable to Incorrect Access Control. An authenticated attacker can manipulate user identifier parameters to bypass authorization controls and gain unauthorized READ and WRITE access to other users' personal information. The API fails to validate that the requesting user is authorized to access the target user's data.
CVSS 8.1
My Safetipin Android Application 5.2.1 - Unauthenticated Authentication Bypass via Hardcoded OTP Credentials
My Safetipin Android Application 5.2.1 contains Hardcoded credentials in the authentication module, which allows remote attackers to bypass authentication and gain unauthorized access to user accounts via predictable OTP values.
CVSS 9.8
ttttonyhe OBlog tags.php cross site scripting
A security vulnerability has been detected in ttttonyhe OBlog up to 3ca6a45a2fcc81f6086751d8af124658720e8f8f. This issue affects some unknown processing of the file /tags.php. Such manipulation of the argument day leads to cross site scripting. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS 4.3
Gitea prior to 1.27.0 SSRF via Migration URI Fetch Bypass
Gitea prior to 1.27.0 contains a server-side request forgery vulnerability that allows authenticated attackers to bypass SSRF protections by exploiting HTTP fetch operations in migration and OAuth avatar code paths that use Go's default http.Get without a custom DialContext. Attackers can supply arbitrary URLs through release asset download URLs, pull-request patch URLs, or OAuth avatar endpoints to reach internal services, cloud instance-metadata endpoints, or read local files such as the application configuration containing database credentials and signing secrets, with exfiltrated content persisted as migration release assets for later retrieval.
CVSS 7.6
PraisonAI: GitHub Actions Claude workflow command injection via unquoted PR branch name
PraisonAI is a multi-agent teams system. In versions prior to 4.6.40, the bundled Claude GitHub Actions workflow is vulnerable to command injection because it embeds an attacker-controlled pull request branch name into a Bash run: block without quoting or validation. Additionally, the workflow allows any @claude comment to trigger the job regardless of whether the commenter is a trusted collaborator. An outside contributor can open a pull request from a fork whose branch name contains shell metacharacters and comment @claude, causing Bash to execute arbitrary shell code in the GitHub Actions runner. Because these commands run in a job holding a GitHub App token with write permissions, OIDC access, and gh/git access, the injection can be chained through $GITHUB_PATH to compromise later privileged steps, enabling repository writes, pull request and issue manipulation, or OIDC-token abuse. This issue has been fixed in version 4.6.40.
CVSS 10.0
livebook - Unescaped Deployment Environment Variables in Generated Setup Commands
Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) vulnerability in livebook-dev livebook allows command injection into generated deployment setup commands.
LivebookWeb.Hub.Teams.DeploymentGroupAgentComponent.docker_instructions/2 and LivebookWeb.Hub.Teams.DeploymentGroupAgentComponent.fly_instructions/4 in lib/livebook_web/live/hub/teams/deployment_group_agent_component.ex interpolate deployment group environment variable values into the generated Docker and Fly.io setup commands without shell escaping. The values originate from the deployment group configuration and reach the sinks through Livebook.Hubs.Dockerfile.online_docker_info/3.
Both sinks place the value inside a double-quoted shell word, so a value containing a command substitution such as $(...) or backticks is evaluated by the shell without any need to break out of the quoting, and a literal double quote terminates the quoted word and allows arbitrary further tokens. The generated command is displayed in the Livebook web interface with a copy button, so a user who copies it and runs it without reviewing it first executes the injected commands on their own machine, under their own account.
An attacker requires privileges sufficient to set deployment group environment variables, while the resulting code execution occurs on the machine of whoever runs the generated command. The Kubernetes instructions are not affected, because they render the same values into a YAML manifest with escaping rather than into a shell command.
This issue affects livebook: from 0.13.0 before 0.18.7 and from 0.19.0 before 0.19.9.
JS-view sandboxed output can synthesize keyboard events to trigger unconfirmed global shortcuts
Origin Validation Error vulnerability in livebook-dev livebook allows untrusted notebook output JavaScript to trigger session-wide keyboard shortcuts, including forced evaluation of all cells and runtime restart.
Livebook's JS-view feature renders notebook-defined JavaScript inside a sandboxed, cross-origin iframe specifically because that JavaScript is untrusted. The trusted iframe shell in iframe/priv/static/iframe/v5.html forwards every keydown event fired in its own window to the parent page without consulting Event.isTrusted, so an event synthesized by the untrusted script through window.dispatchEvent is forwarded exactly as a genuine keystroke would be. The parent-side relay in assets/js/hooks/js_view.js reconstructs and re-dispatches it on the live page with no further validation, and because assets/js/hooks/session.js registers the global shortcut handler on the document in the capture phase, that handler acts on the replicated event regardless of how it was produced.
Sandboxed output JavaScript can therefore drive Livebook's session-wide keyboard shortcuts. Two of them reach LivebookWeb.SessionLive and execute immediately with no confirmation: the shortcut for queueing full evaluation runs every cell in the notebook, and the shortcut for reconnecting the runtime disconnects and reconnects it, discarding in-memory state. A third shortcut deletes the focused cell behind a confirmation dialog that the user can permanently dismiss, after which it too executes silently.
Forced full evaluation is the significant consequence, because it causes the notebook's own Elixir code to run without the user choosing to evaluate anything. A user who merely opens a notebook obtained from a third party, or reached from published documentation, can have its code executed on their runtime. Livebook also mirrors cell outputs to every connected client, so a malicious output triggers in a collaborator's browser as soon as it renders.
This issue affects livebook: from 0.5.0 before 0.18.7 and from 0.19.0 before 0.19.9.
Livebook - Arbitrary File Write via Imported File Entry Path Traversal
Relative Path Traversal vulnerability in livebook-dev livebook allows an attacker-authored notebook to write a file with attacker-controlled content to an arbitrary path.
A .livemd notebook can declare file_entries metadata, each entry carrying a name. Every path that creates a file entry through the user interface validates that name with Livebook.Notebook.validate_file_entry_name/2, which requires a flat filename of alphanumerics, dashes, underscores and dots, ending in an extension. The import path does not: Livebook.LiveMarkdown.Import.file_entry_metadata_to_attrs/1 in lib/livebook/live_markdown/import.ex takes the name verbatim from the notebook source.
For a URL-type file entry, Livebook.Session.file_entry_cache_file/2 in lib/livebook/session.ex resolves that name beneath the session's temporary directory without checking that the result stays inside it, and Livebook.FileSystem.Utils.resolve_unix_like_path/2 collapses parent-directory segments while clamping only at the filesystem root. When the entry's content is requested and no cached copy exists, Livebook fetches the entry's URL and writes the response body to the resolved path, creating parent directories as needed. The attacker therefore controls both the destination and the contents of the written file, which may land anywhere the Livebook process can write. The same missing containment check is present in Livebook.Session.to_attachment_file_entry/2.
A victim who opens an attacker-supplied notebook and causes the entry to be fetched triggers the write within their own authenticated session; the attacker needs no account on the target instance. URL-type entries are also not placed under notebook stamping quarantine on import, so no warning is shown.
This issue affects livebook: from 0.11.0 before 0.18.7 and from 0.19.0 before 0.19.9.
Livebook Teams identity callback lacks state binding, allowing login CSRF
Cross-Site Request Forgery (CSRF) vulnerability in livebook-dev livebook allows an attacker to authenticate a victim's browser session under the attacker's own Livebook Teams identity.
When Livebook is configured to use Livebook Teams for identity, Livebook.ZTA.LivebookTeams.handle_request/4 in lib/livebook/zta/livebook_teams.ex handles the OAuth-style callback carrying a teams_identity marker and a code parameter. The clause exchanges that code for an access token and writes the token into the browser session without verifying any value that ties the callback to the browser session that started the login. No state or nonce is generated when the flow is initiated: Livebook.Teams.Requests.create_auth_request/1 in lib/livebook/teams/requests.ex sends an empty request body, so no per-attempt value is ever registered, and the callback clause has nothing to compare against.
An attacker who holds membership in the same Livebook Teams organisation as the target instance can therefore begin the login flow themselves, retain the resulting authorization code without redeeming it, and induce a victim to open a crafted URL carrying that code. The victim's browser completes the exchange and the resulting session is bound to the attacker's identity rather than the victim's. The victim is not required to hold any particular privilege, and no credential belonging to the victim is involved. The vulnerability does not allow the attacker to authenticate as the victim.
The consequence is that a user believes they are working in their own authenticated session while they are in fact operating as another identity. Work performed in that session is attributed to the attacker's account, and secrets, uploaded data, or notebook results the victim produces are exposed to the attacker rather than kept in the victim's own account. The authorization code must be redeemed within a short window after the login flow begins, which constrains the timing of the attack but not its feasibility.
This issue affects livebook: from 0.15.0 before 0.18.7 and from 0.19.0 before 0.19.9.
By Source