Ruby
Monthly
OS command injection in the image_optimizer Ruby gem versions 1.3.0 through 1.9.0 allows unauthenticated remote attackers to execute arbitrary shell commands with the privileges of the Ruby process by supplying an image path containing shell metacharacters such as ';'. The flaw is reachable only when the consuming application enables the 'identify' option (so that ImageOptimizer#identify_format runs) and the attacker controls the image path argument, typically through an attacker-chosen uploaded file name, which means real-world impact is bounded by the OS privileges of the Ruby/web worker process and by whether user-controlled filenames reach the gem. The CVSS 4.0 base score of 9.3 reflects high confidentiality, integrity and availability impact, and no public exploit identified at time of analysis; the included gist and VulnCheck advisory serve as the primary public technical disclosures.
Unbounded resource allocation in the Ruby bindings of Apache Thrift (versions before 0.25.0) lets unauthenticated remote clients exhaust server memory or CPU by sending Thrift messages whose declared structure or container sizes trigger excessive allocation while the service deserializes them. Only network-reachable services that actually accept and parse untrusted Thrift payloads through the Ruby bindings are exposed, and the impact is confined to availability, with no data disclosure or modification (C:N/I:N/A:H). The Apache Software Foundation has released 0.25.0 as the fix; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor rates this 8.2 (High) under CVSS 4.0, while our independent assessment also treats it as High severity but notes a higher attack complexity (AC:H in v3.1 terms) because the attacker must reach a service that parses untrusted Thrift messages.
Polynomial-time regular expression denial of service (CWE-1333) in the crmne/ruby_llm Ruby gem's Mistral provider capability matching allows unauthenticated remote attackers to exhaust CPU and stall requests by feeding a crafted model-identifier string into the modalities_for/capabilities_for code path, but only on hosts running Ruby 3.1.x, whose regex engine lacks the linear-time matching optimization. Availability is the sole impacted property (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), and the practical limiter is deployment context: the host application must route untrusted, attacker-influenced model IDs into this matching logic, since hardcoded or whitelisted model IDs neutralize the vector. CISA SSVC records Exploitation: none and there is no public exploit identified at time of analysis; an upstream fix exists in commit dd3c84812598def03d4aff77b5447c41d8f5c34e.
Polynomial-time regular expression denial-of-service in the crmne/ruby_llm library's <think>-tag response parsing can be triggered when a model response contains many unterminated <think> tags, driving excessive CPU consumption and delaying chat-completion processing. Only deployments pinned near commit fa6f279847d6d7027814539d9c0dfc3bbdfd2a83 and running on Ruby 3.1.x are affected, since Ruby 3.2+ regex engine optimizations mitigate the backtracking; RubyLLM exposes no direct network surface of its own, so an attacker must be able to shape the upstream LLM response (malicious/compromised model endpoint, prompt injection, or interception of the model API connection). No public exploit code has been identified at time of analysis, EPSS is 0.17% (5th percentile), and there is no CISA KEV listing; the consensus signal is a low-priority issue despite the vendor-assigned 7.5 score, with real impact limited to CPU consumption and processing delay in the request handling the response.
Server-side request forgery in Stringer, a self-hosted RSS reader, allows an authenticated low-privileged user to make the server issue arbitrary HTTP/HTTPS requests to internal network hosts, loopback services, and cloud metadata endpoints such as AWS IMDS at 169.254.169.254. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L, base 7.6) confirms a network-reachable, low-complexity attack requiring only an authenticated account - a barrier that collapses to near-anonymous when self-service signup (Setting::UserSignup) is enabled, since any visitor can register. Impact ranges from internal port and service scanning to theft of cloud IAM credentials when Stringer runs on a cloud instance with an attached role reachable via IMDSv1; there is no public exploit identified at time of analysis and no confirmed CISA KEV active exploitation, though the attack surface is trivial to exercise for anyone holding a valid session.
S/MIME signature spoofing in Zammad before 7.1.2 lets a remote, unauthenticated sender forge email that Zammad displays with the same 'validly signed' indicator as a genuine message, by presenting a self-made certificate whose subject name matches a certificate already stored for a real, previously trusted sender - no access to that sender's private key is required. Exploitation requires inbound S/MIME signature verification to be enabled on the target instance, a certificate to already exist for the impersonated sender, and a human (agent/user) to view and act on the forged ticket, so impact is confined to integrity/spoofing with no data disclosure or service disruption. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor fix exists in 7.1.2, and the flaw is genuine rather than inflated CVSS.
An authenticated broken-access-control flaw in Zammad's External Data Source feature lets any logged-in user - including a minimal customer-level account - read records that do not belong to them by supplying another record's numeric ID. The affected component builds a 'render context' from request parameters such as ticket_id, customer_id, user_id, group_id, and organization_id and passes it to the configured external system lookup without first checking whether the requesting user is permitted to see that record, so enumerable IDs leak ticket, user, group, and organization details. The issue affects Zammad versions prior to 7.1.2, where the vendor-released patch (7.1.2) adds an explicit authorization check; no public exploit code or confirmed active exploitation was identified at time of analysis.
Zammad's SSO auto-linking logic can be abused to take over any existing local account, including agent and administrator accounts, because it binds an incoming third-party identity to a local user purely by matching the email address the identity provider reports. An unauthenticated remote attacker only needs to control one identity at any provider configured on the target instance - with Zammad's default multi-tenant Microsoft 365 /common app registration, any Azure AD tenant qualifies - set that identity's email to the victim's address, then authenticate and be logged in as that victim without ever knowing their local password. Exploitation requires the 'Automatic account link on initial logon' setting to be enabled and at least one SSO provider configured; no public exploit code has been identified at time of analysis and the issue is confirmed fixed in Zammad 7.1.2.
Authenticated administrators of the Zammad helpdesk platform (versions prior to 7.1.2) can achieve remote code execution on the Zammad server by injecting specially crafted text into an AI Agent configuration field that bypasses the application's ERB sanitizer. Because the pre-7.1.2 sanitizer used Ruby's `.sub` and escaped only the first `<%` opener, an attacker with AI Agent create/edit permissions can smuggle a nested ERB tag (e.g. `<%<%= ... %>`) that executes automatically the next time the affected agent processes a ticket, with no interaction from other users required; this yields full read/write/delete access to data on the host (VC:H/VI:H/VA:H). The flaw is a genuine remote code execution issue, not a mislabeled availability problem, and it requires admin-level privileges (PR:H) plus the optional AI Agent feature being in active use; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor fix ships in Zammad 7.1.2 (GHSA-gp3x-9xm8-rcj6).
Unauthenticated denial of service in Zammad prior to 7.0.2 allows any remote attacker who can reach the host to tie up a Puma request worker for roughly 115 seconds per request by POSTing to /api/v1/import/otrs/import_check. The import_check and import_status actions are missing the setup_done_response guard that other actions in the same controller enforce, so they run against fully set-up production instances, where the code enters a retry loop against a blank OTRS endpoint and sleeps 30 s then 45 s between attempts. Each request costs the attacker almost nothing, so a sustained rate of just a few requests per second saturates the worker pool and keeps the instance unavailable as long as the traffic continues; no account, valid import configuration, or target knowledge beyond the hostname is required, and the CSRF token is trivially harvested from any prior GET response. This is a genuine availability risk that is trivial to trigger, but no public exploit code or confirmed active exploitation has been identified at time of analysis.
Improper privilege management in Zammad helpdesk/customer support systems allows an attacker holding a valid but deliberately restricted API token to create new administrator accounts, inheriting the latent authorization authority of the token's parent account instead of honoring the token's granular scope. This affects all Zammad releases prior to 7.0.2 and 7.1.0, and exploitation is authenticated (CVSS PR:L) since a scoped token must already be held, though no user interaction is required and the vector is network-reachable; success grants full access to tickets, customers, and configuration and effectively hands the attacker complete control of the instance. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), but the independent assessment rates it a genuine high-priority privilege-escalation flaw rather than a high-CVSS-but-low-risk case, and EPSS-style risk is elevated by the trivial post-exploitation payoff.
Stored cross-site scripting in Zammad prior to 7.0.1 lets an authenticated low-privilege user persist arbitrary HTML markup and JavaScript event handlers inside a ticket title through the normal ticket-creation workflow, because the title is stored without sanitization and later rendered unescaped. The payload fires when a victim - typically a support agent or administrator with an active session - opens the affected ticket or receives a notification, escalation or reminder email that interpolates the title, yielding script execution in the victim's browser context. No public exploit code has been identified at time of analysis, the flaw is not listed as actively exploited, and exploitation requires both an authenticated account with ticket-creation rights and victim interaction; Zammad 7.0.1 contains the vendor fix.
An authenticated GitLab EE user can read sensitive CI/CD variable values from debug-mode job traces via the Duo AI troubleshooting feature because of a missing authorization check (CWE-862). Affected versions are GitLab EE 18.7 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1. Exploitation is gated behind authentication and requires the non-default combination of CI_DEBUG_TRACE debug tracing and the Duo AI feature, and no public exploit code has been identified at time of analysis; this is a moderate-priority issue rather than a critical one.
Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in user, including one with only low-tier permissions, execute arbitrary Ruby and Python code on the COSMOS server and its per-target decom microservices. COSMOS reads configuration from a user-writable overlay (targets_modified/) before its read-only targets/ tree and then executes that content - rendering it as ERB, eval-ing GENERIC_READ/WRITE_CONVERSION blocks, or require-ing Script Runner procedure files - so an attacker who can write to the overlay via the screen-save or storage-upload endpoints achieves code execution as the openc3 user, which holds Redis and object-store credentials and sits on the internal service network. A working proof-of-concept is published in the vendor GitHub advisory, and the vendor has released 7.3.0 as the fix; no confirmed active exploitation (CISA KEV) has been reported. Reachability is limited on default single-host installs because the shipped docker-compose binds Traefik to 127.0.0.1:2900, so exploitation is realistic on multi-user deployments that expose the web port.
Authenticated OS command injection in OpenC3 COSMOS 5.12.0 through 7.2.1 allows a user with a valid session to run arbitrary operating-system commands as the openc3 service user by writing shell metacharacters into the pypi_url setting and then installing a plugin that carries Python dependency metadata. The injected value is interpolated into a shell backtick inside PluginModel.install_phase2, so commands execute with access to the service's Redis and bucket storage credentials; in the open-source edition any authenticated user can reach both the setting-write and plugin-install operations, whereas the Enterprise edition requires the administrator role, and the vendor has fixed the issue in 7.3.0. There is no CISA KEV listing or confirmed in-the-wild exploitation, but the public vendor advisory GHSA-vp3w-52v9-q57f includes confirmed end-to-end proof-of-concept steps, and the independent assessment rates this as a genuine high-priority issue rather than CVSS inflation.
Code injection in Mongoid allows unauthenticated attackers who can influence a query argument to execute arbitrary JavaScript in the MongoDB server via a string-typed query criterion, leading to disclosure of stored field values, unintended document selection for writes, and reduced database performance. The vulnerability affects Mongoid versions 8.0.0 through 8.0.12, 8.1.0 through 8.1.12, 9.0.0 through 9.0.11, and 9.1.0, but exploitation requires the application to pass externally influenced string criteria to the query builder and the MongoDB deployment to permit server-side JavaScript evaluation. No public exploit identified at time of analysis.
Unauthenticated, remote query-operator injection in Mongoid - the official MongoDB object-document mapper for Ruby - allows an attacker to shape how MongoDB evaluates a query whenever an application forwards externally supplied filter parameters straight into Mongoid query-building methods without whitelisting allowed operators. Successful abuse can disclose stored field values (for example through $ne, $gt or $regex-style filter logic used for blind extraction) and, because operators such as $regex or $where can force expensive scans, can degrade database performance. The impact is conditional: the vendor's CVSS 4.0 vector carries AT:P (attack requirements present) and our assessment uses AC:H, because exploitation depends entirely on the downstream application's query-construction pattern rather than on a Mongoid setting. No public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided. CVSS 4.0 base is 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L) and our independent CVSS 3.1 assessment is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L, i.e. high confidentiality impact with a limited availability effect and no integrity impact.
CPU exhaustion in MongoDB's Mongoid Ruby ODM allows an unauthenticated remote party to render an embedding application unresponsive by supplying crafted text that lands inside a pattern-matching query condition Mongoid evaluates in memory against an embedded association, triggering catastrophic regex backtracking (CWE-1333, ReDoS). The impact is availability-only: the affected Ruby application process burns CPU and stops responding, with no confidentiality or integrity effect. No public exploit code has been identified at time of analysis, and reachability depends on a specific application coding pattern, which is why the independent assessment applies AC:H and treats deployments that never route untrusted input into regex conditions on embedded documents as out of scope (the CNA's CVSS 4.0 vector rates it 8.7 with AC:L, a more aggressive reading than the assessed CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).
Data disclosure and permanent record deletion in Mongoid can be triggered by an unauthenticated remote attacker when an application passes an externally supplied field name to certain in-memory query methods for embedded documents, exploiting an unsafe reflection weakness (CWE-470). The vendor CVSS 4.0 base score of 9.2 reflects the network vector and high impact across confidentiality, integrity, and availability, though the attack requires a developer-dependent data flow (AT:P) where untrusted input reaches a field name parameter. No public exploit code or active exploitation has been identified at time of analysis, and affected/fixed versions remain unconfirmed due to an unbounded CPE (mongoid:*).
Silent, warning-free failure of encryption-configuration generation in the Mongoid object-document mapper causes fields that an application explicitly declared for client-side field-level encryption (CSFLE) to be written to MongoDB as cleartext, allowing any party with ordinary read access to the database - a DBA, a read replica, a backup, or a lower-privilege account with query rights - to read values that were intended to be protected from them. Only applications built on Mongoid that use MongoDB CSFLE and declare fields for encryption are affected; the CVSS vectors (the supplied 4.0 vector with PR:L and the independently assessed 3.1 vector with PR:L) indicate the attacker requires some existing privilege, consistent with the assessed precondition of ordinary database read access rather than an unauthenticated remote path. No public exploit code has been identified at time of analysis, and this is assessed as a genuine but conditional data-protection failure rather than an actively exploited priority.
Mongoid can silently persist values in readable form that applications intended to encrypt, because its client-side field-level encryption (CSFLE) schema generation omits encryption rules for fields declared on embedded models - the MongoDB driver then writes those values unencrypted with no error or warning. The exposure is limited to applications that both enable CSFLE and declare encrypted fields on embedded documents (top-level fields are not implicated), and to parties who already hold read access to the database, a backup, or the underlying on-disk data files; there is no write, integrity, or availability impact and no remote code execution. Data-level risk is real but bounded: no public exploit code identified at time of analysis, no confirmed active exploitation, and the reported CVSS 4.0 base score of 7.1 is consistent with the independent CVSS 3.1 assessment of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
Unsafe reflection (CWE-470) in Mongoid's document persistence layer allows a crafted key to be reflected into an internal method invocation instead of the intended array-field update, which can delete stored records and render the embedding application unresponsive. The affected component is Mongoid, MongoDB's Ruby object-document mapper; the CPE record (cpe:2.3:a:mongodb_inc.:mongoid:*:*:*:*:*:*:*) carries no version bounds, so the vendor has not published a bounded version range, and exposure applies to any embedding application that forwards unauthenticated, attacker-controlled keys directly into an array-field update. The CVSS 4.0 vector marks this dependency as AT:P (Attack Requirements: Present), meaning Mongoid is not exploitable in isolation, but where that non-default coding pattern exists there is no authentication or user-interaction barrier (PR:N, UI:N/A:H). Impact is integrity and availability only (VI:H/VA:H, VC:N), and no public exploit code has been identified at time of analysis.
Insecure direct object reference in Mongoid's nested-attributes handling lets an authenticated user with basic application privileges supply another user's record identifier, causing Mongoid to look up that record outside ownership or tenant scoping and then update and link it to the requester's own record-resulting in unintended disclosure and unauthorized modification of data. Exploitation is limited to applications that use accept_nested_attributes_for on ownership- or tenant-scoped associations and rely on Mongoid to enforce scoping; no public exploit identified at time of analysis, and no confirmed affected or fixed versions because the only reference is an unbounded MongoDB Jira advisory with a wildcard CPE.
HTTP request smuggling via inconsistent request framing in Puma's native http11_parser (reported range Puma 5.0.0 through 8.0.3) allows a remote, unauthenticated attacker to desynchronize request boundaries between Puma and an upstream HTTP intermediary, enabling request hijacking, cache poisoning, or bypass of front-end access controls; the description's claim of arbitrary code execution is unverified and inconsistent with CWE-444. Exploitation is deployment-dependent: it requires a reverse proxy, CDN, or load balancer whose parsing of ambiguous Content-Length/Transfer-Encoding framing diverges from Puma's, which is why our independent assessment rates it AV:N/AC:H/PR:N/UI:N/S:C rather than the published 9.1. Risk signals are weak and conflicting - EPSS is 0.17% (6th percentile), there is no CISA KEV listing and no confirmed public exploit code, and the only third-party reference is an unverified GitHub issue - so raw severity should be discounted.
Unbounded memory exhaustion in Ruby's resolv gem (before 0.7.2) allows an attacker controlling DNS responses to permanently grow a target process's memory without limit, eventually crashing the service. The root cause is that Resolv::DNS::Resource.get_class and related methods register a new Ruby class as a constant for each unknown DNS resource record type/class pair encountered, preventing garbage collection for the lifetime of the process. Because resolv is a default Ruby gem requiring no installation step, any plain Ruby installation performing DNS resolution - web services, workers, CLI tools - is exposed without opt-in configuration, and no public exploit has been identified at time of analysis.
Heap-use-after-free in the Ruby json gem's native C extension (versions 2.20.0 through 2.21.1) allows an unauthenticated remote attacker to crash the Ruby process by supplying a crafted truncated JSON stream with duplicate object keys to any application using JSON::ResumableParser. The root cause is that the parser's input buffer is freed without resetting the state.start, state.cursor, and state.end pointers, which are subsequently dereferenced when partial_value processes the duplicate-key warning path via cursor_position, producing a heap-use-after-free confirmed by AddressSanitizer and a native SIGSEGV on official RubyGem releases. Impact is limited to availability - no code execution or information disclosure is claimed - and no public exploit code has been identified at time of analysis, though a private end-to-end TCP proof-of-concept was submitted with the advisory.
Use-after-free in Ruby 4.x (before 4.0.5) lets remote attackers who can manipulate DNS response timing crash applications calling Addrinfo.getaddrinfo with a timeout: option or Socket.tcp with resolv_timeout:. The flaw lives in the pthread-based getaddrinfo timeout handler (rb_getaddrinfo in ext/socket/raddrinfo.c) and, while reliably exploitable for denial of service, also raises a theoretical possibility of memory-corruption-based code execution. No public exploit identified at time of analysis.
Remote code execution in Ruby ERB library via unsafe deserialization allows unauthenticated attackers to execute arbitrary code by exploiting incomplete protection in Marshal.load workflows. While ERB 2.2.0+ added guards to prevent code execution during deserialization in result() and run() methods, the def_module(), def_method(), and def_class() methods remained unprotected, enabling attackers to bypass the @_init safeguard. Exploitation requires high complexity (AV:N/AC:H) as applications must deserialize untrusted Marshal data with ERB loaded. No EPSS or KEV data available; exploitation likelihood depends on prevalence of unsafe Marshal.load patterns in Ruby codebases.
Remote code execution in Manyfold prior to version 0.133.0 allows authenticated users to execute arbitrary commands by uploading a ZIP archive with specially crafted filenames containing shell metacharacters that are passed unsanitized to Ruby backtick execution. The vulnerability affects the model render generation feature and requires an attacker to be logged in, with public exploit code currently available. A patch is available in version 0.133.0 and later.
Stored XSS in Bugsink error tracking tool before 2.0.13 allows unauthenticated attackers to inject persistent scripts through error event submissions. PoC and patch available.
Use After Free vulnerability in Apache Arrow C++. This issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. [CVSS 7.0 HIGH]
Spree Commerce's guest checkout feature contains an insecure direct object reference (IDOR) flaw that allows unauthenticated attackers to access other customers' personally identifiable information by manipulating address parameters during transaction processing. Public exploit code exists for this vulnerability, which affects all guest checkout flows across multiple Spree versions. Patches are available for versions 4.10.3, 5.0.8, 5.1.10, 5.2.7, and 5.3.2.
Spree versions up to 4.10.2 is affected by authorization bypass through user-controlled key (CVSS 7.5).
Razorpay IFSC Ruby gem through version 2.0.62 is affected by a server-side request forgery (SSRF) vulnerability. Unauthenticated remote attackers can supply a crafted IFSC code to IFSC.find or IFSC#get - such as a network-path reference (//evil.host) or an absolute URI - that Ruby's URI.join resolves as a new host, redirecting API requests to internal or attacker-chosen hosts and returning parsed response fields. Exploitation requires the consuming application to pass untrusted input directly to these methods; impact is limited to low confidentiality (CVSS 4.0 base 6.9) with no write or availability effect, and no public exploit has been identified at time of analysis.
Cross-origin credential leakage in the Mechanize Ruby library (versions prior to 2.14.1) allows attackers who control a redirect target to capture bearer tokens, session cookies, Proxy-Authorization credentials, or Cookie2 values that the calling application supplied through Mechanize#request_headers= or the per-request headers argument. The flaw is conditional: it only triggers when an application actually sets credentials via those header APIs and a response issues a cross-origin HTTP redirect (or a cross-origin meta refresh), so same-origin redirects are unaffected and credentials managed through Mechanize#cookie_jar or Mechanize::HTTP::AuthStore are explicitly out of scope; there is no public exploit identified at time of analysis. Because the attacker must influence the redirect destination rather than merely reach the service, this is a genuine but conditional information-disclosure issue (CWE-200) rather than a mass-exploitation priority.
Credential-header leakage in the Ruby Mechanize gem before 2.14.1 allows sensitive headers to be forwarded to a lower-trust destination during redirect following, because Mechanize::HTTP::Agent#response_redirect considered a redirect same-origin whenever the host matched, without comparing scheme or port. A same-host HTTPS-to-HTTP downgrade can put caller-supplied Authorization (or Proxy-Authorization) and Cookie (or Cookie2) headers on the wire in cleartext, and a same-host redirect to a different port can deliver a caller-supplied Cookie to an unrelated service listening there. Per the assessed vector (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) the impact is confidentiality-only with no integrity or availability effect, and no public exploit was identified at time of analysis; the practical risk is limited because the consuming application must explicitly inject its own credential headers and an attacker must control or man-in-the-middle the redirect response, while cookies held in Mechanize#cookie_jar are scoped correctly and are not leaked. Vendor-released patch: 2.14.1.
Credential leakage in the Ruby Mechanize library before 2.14.1 lets an attacker who controls page content encountered during a crawl capture bearer tokens or session cookies, because a cross-origin meta refresh caused Mechanize::HTTP::Agent#response_follow_meta_refresh to reapply the caller's global default headers to the refresh request. Exploitation is conditional and rated AC:H: Mechanize#follow_meta_refresh must be explicitly enabled (it defaults to false), the caller must have placed sensitive credentials in the agent-wide default headers via Mechanize#request_headers=, and the attacker must be able to serve attacker-controlled markup to the crawl, though the request itself is unauthenticated (PR:N) and requires no user interaction (UI:N). There is no KEV entry, no public exploit identified at time of analysis, and no EPSS score supplied; the vendor-released fix is Mechanize 2.14.1, where cross-origin meta refreshes now discard credential and cookie headers under the same origin rules as HTTP redirects.
Object-level authorization bypass in owen2345 Camaleon CMS through 2.9.2 lets an authenticated user who holds only the media-library permission (`:manage, :media`) overwrite another user's avatar by calling the admin media crop endpoint with the `saved_avatar` parameter set to a victim's user ID. The crop action reaches the same avatar meta write that `UsersController#update` protects with `:manage, :users`, but enforces only the media permission, so the media library becomes a side door into profile editing; post-PR-#1267 the target is scoped to `current_site.users`, limiting the bypass to same-site, cross-user writes rather than cross-tenant ones. Publicly available exploit code exists (CVSS 4.0 vector carries E:P), and the vendor has released a fix in 2.9.3; the exposure is limited to profile-meta tampering with no access to passwords, credentials, or confidential data, so the assessed risk is genuinely low. No confirmed active exploitation (CISA KEV) was identified at time of analysis.
Incomplete masking of Microsoft Graph bearer tokens in Zammad's HTTP log allows an authenticated Zammad administrator with Microsoft Graph channel access to read the payload and signature segments of a still-valid mailbox access token from stored log entries, exposing sensitive JWT claims such as account scope, tenant and timing that could assist in reconstructing the full token while it remains valid. Only Zammad deployments older than 7.1.2 that use a Microsoft Graph email channel and that have recorded a failed Graph API request are affected; the flaw is gated by high administrative privilege and is not remotely reachable by unauthenticated users, and no public exploit identified at time of analysis. The vendor-released patch is Zammad 7.1.2, and independent assessment rates this as a low-severity information-disclosure issue consistent with the CVSS 4.0 score of 5.1.
Improper URL sanitization in Zammad's inbound-email/ticket HTML scrubber lets an attacker embed traversal-laden <img src> or srcset URLs that survive the remote-URL check; when an authenticated agent simply views the message, the browser resolves the URL to a same-origin Zammad API endpoint and issues the request with the agent's session cookie, producing disruptive state changes such as forced logout with no further interaction. The attacker needs no Zammad account (the payload is delivered as ordinary inbound email or ticket content), but the effect only triggers on agent view (UI:P) and is confined to low-integrity/low-availability same-origin calls rather than data exfiltration. Exploitation status: no public exploit identified at time of analysis; a vendor-released patch is available in Zammad 7.1.2.
An improper PGP signature verification flaw in Zammad 7.0.3 and 7.1.1 lets a remote, unauthenticated sender have an inbound email article saved with a successful 'Good signature' status even though the displayed message body is not actually covered by that signature, misleading agents who trust the indicator. Exploitation requires the inbound PGP secure-mailing feature to be configured with a registered/trusted sender key and possession of a genuine opaque ('-----BEGIN PGP MESSAGE-----') signed message from that sender, which is replayed while the displayed body is swapped; an agent must open the article and rely on the signature indicator (UI:R). The impact is limited to integrity of the displayed content, not confidentiality or availability, and no public exploit has been identified at time of analysis. Zammad fixed the issue in version 7.1.2.
Zammad 7.0.3 and 7.1.1 return stored LDAP and Exchange integration credentials in cleartext through the integration administration API, allowing an authenticated administrator to read secrets the UI is supposed to mask. Because the vulnerable endpoints are the import 'job_try' responses, a user holding full admin rights - and only such a user - can recover the LDAP bind password, the Exchange EWS password, or a stored OAuth access token, plus raw request parameters that leak into the persisted ImportJob payload. Per the supplied vector the issue requires high privileges (PR:H) and results in confidentiality impact only, with no code execution or data modification; there is no public exploit identified at time of analysis, and the vendor-released fix is Zammad 7.1.2.
Stored cross-site scripting in Zammad's Knowledge Base video widget lets an authenticated user who holds Knowledge Base editing rights for a category publish an answer whose crafted video 'id' value breaks out of the generated <iframe> attribute context and injects arbitrary HTML; when a second, more privileged user who can switch between user sessions opens that published answer, the injected markup silently fires a request to Zammad's session-switching endpoint and forces the victim's session onto an account chosen by the attacker. Exploitation requires two distinct privileges (a Knowledge Base editor on the attacker side and session-switch/impersonation permission on the victim side) plus the victim simply viewing the published answer, and no public exploit code has been identified at time of analysis. The flaw is tracked as CWE-79 and is fixed in Zammad 7.1.2; the circumstances make this a genuine but conditionally gated stored XSS that chains into a forced session-switch account takeover rather than a raw remote flaw.
Authenticated users of the Zammad helpdesk platform prior to 7.1.2 can read the tag names assigned to any ticket, including tickets they are not authorized to view, because the tag-list/autocomplete endpoint enforced no ticket-scoped authorization. Any account that can authenticate - including low-privilege customers or limited agents - can query the endpoint and, since ticket IDs are sequential integers, enumerate ticket tags in bulk to infer internal categorization and potentially sensitive labels. The exposure is confidentiality-only (no data modification or denial of service), no public exploit code has been identified at time of analysis, and the flaw is fully corrected in Zammad 7.1.2, where the endpoint is restricted to ticket.agent, admin.tag, and knowledge_base.editor permissions.
Information disclosure in the Zammad helpdesk/customer support system versions prior to 7.1.2 allows a remote, unauthenticated party to embed a tracking pixel that evades the built-in HTML sanitizer, so that when an agent views the crafted ticket or email the recipient's browser silently loads an external image and leaks read-receipt metadata such as when and by whom the ticket was opened. Exploitation requires the recipient to open the article in a browser (CVSS 4.0 base score 5.3; independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and impact is bounded to open-time and viewer-fingerprint disclosure rather than ticket contents, credentials, or code execution. No public exploit code has been identified at time of analysis and the CVE is not in CISA KEV; the vendor-released fix is version 7.1.2.
Zammad helpdesk versions prior to 7.1.2 let an authenticated channel administrator read attachments outside their authorized groups by embedding an existing attachment ID in an email signature. The signature processor copies the referenced attachment into a signature-owned record and then serves it based on the copy's ownership rather than the original ticket or knowledge-base object, creating an authorization bypass (CWE-639). The vendor fixed this in 7.1.2; exploitation requires one of the channel-admin permissions and no public exploit code has been identified at time of analysis.
Zammad helpdesk instances prior to 7.1.2 expose a legacy destroy_form action on AttachmentsController that deletes temporary UploadCache store records using only a caller-supplied form_id and performs no ownership verification (CWE-862), so an authenticated user who knows another user's pending-upload UUID can silently wipe that user's in-progress attachments before the ticket or article is submitted. Exploitation requires a valid account on the instance plus knowledge of the victim's non-enumerable form_id UUID and only affects files still in the transient pre-submission cache, which is why the base score is a low 2.3 under CVSS 4.0 (equivalently AV:N/AC:H/PR:L/UI:N/C:N/I:L/A:L on CVSS 3.1). No public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in Zammad 7.1.2.
Broken access control in Zammad's GraphQL API allows an authenticated user to read taskbar item data - transient session state that can include auto-saved ticket drafts - belonging to another user by supplying that user's taskbar identifier. The flaw affects Zammad versions prior to 7.0.2 and was addressed upstream in the 7.0.2 release, which adds the missing authorization checks. Exploitation requires a valid low-privilege account (authenticated) plus knowledge or enumeration of the target taskbar item ID; there is no public exploit code identified at time of analysis, and impact is limited to a single victim's taskbar item per request.
Session-termination vulnerability in Zammad helpdesk/customer-support deployments running versions prior to 7.0.2: the HTML sanitizer fails to strip same-origin Zammad API paths from <img> src and srcset attributes, so crafted ticket HTML can reference endpoints such as /api/v1/signout, /api/v1/sessions/switch/N, /api/v1/sessions/switch_back, or /api/v1/getting_started/auto_wizard/<token>, causing the viewing agent's session to be terminated or switched when the ticket is rendered. The attack is unauthenticated per the CVSS 4.0 vector (PR:N) and can be delivered via inbound-email-created tickets, but it requires a second user to view the crafted ticket (UI:P) and is bounded to session availability with no data disclosure or code execution. CVSS 4.0 scores it 5.3 (MEDIUM) and an independent assessment rates it CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L; no public exploit code or CISA KEV entry was identified at time of analysis, and the vendor released 7.0.2 with an allowlist restricting /api/ image sources to attachment endpoints.
Information disclosure in Zammad lets any sender capable of emailing a helpdesk instance embed an arbitrary external URL in the srcset attribute of an image, so that the agent's browser silently fetches attacker-controlled content the moment the ticket is viewed. Zammad's HtmlSanitizer::Strict blocked external URLs in the src attribute but left the equally allowlisted srcset attribute unchecked, leaking the agent's IP address, User-Agent, Referer and the precise viewing time to the sender. All releases before 7.0.2, and 7.1.x releases before 7.1.0, are affected; fixes are available in 7.0.2 and 7.1.0, and no public exploit code was identified at time of analysis. The impact is a privacy/tracking leak rather than code execution or data theft, and it depends on an agent actually opening the crafted ticket in a browser that honours srcset.
Server-side request forgery in Zammad (versions prior to 7.0.2) lets a user who controls their own profile at a connected federated identity provider (OAuth, OIDC, or SAML) make the helpdesk server issue outbound HTTP requests to attacker-chosen addresses, including internal network locations, by supplying a crafted profile image URL. Because the fetch is blind, the attacker infers internal reachability only from differences in response timing and error patterns, and each probe can block a worker process for several seconds, producing a minor availability side effect. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited; exploitation requires a non-default deployment where federated login is configured and the attacker can edit their provider-side profile image URL. Fixed in Zammad 7.0.2.
Missing per-ticket authorization in Zammad's GitHub and GitLab issue-tracker integration endpoints prior to 7.0.2 lets any authenticated agent - including one with no tickets assigned - enumerate ticket IDs and read the titles, statuses, labels, and URLs of external GitHub/GitLab issues linked to tickets they are not permitted to see. The flaw carries CVSS 5.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting a low-confidentiality-impact disclosure confined to authenticated internal users, and yields nothing on instances where the GitHub/GitLab integration is not configured or no tickets carry linked issues. No public exploit code or active exploitation has been identified at time of analysis; the vendor shipped Zammad 7.0.2 as the fix.
Information disclosure in the Zammad helpdesk knowledge base lets an authenticated user who holds the knowledge_base.editor permission in at least one category see answer titles and updated_at timestamps belonging to categories where they have no editor rights, exposed through the global quick search. The leak only occurs in deployments that use granular, per-category permission assignments with differing editor roles; category names are not exposed and opening a leaked answer returns 'Page not found,' so no answer body content is accessible. Exploitation requires a valid authenticated account with the editor permission (PR:L/H depending on the scoring system) and is rated low severity (CVSS 4.0 base 2.1), with no public exploit identified at time of analysis.
Merge request authorship spoofing in GitLab CE/EE 19.1 through 19.4.0 lets an authenticated user who can perform a Direct Transfer import attribute merge request content to arbitrary existing users on the target instance. Exploitation requires a valid account with the ability to run a direct-transfer migration and depends on a timing/state condition in ephemeral cache handling, so it is not deterministic; the assessed impact is integrity-only with no confidentiality or availability effect, and no public exploit identified at time of analysis. GitLab has shipped fixed releases 19.2.7, 19.3.3, and 19.4.1.
Authentication bypass in GitLab Enterprise Edition lets an authenticated user holding developer-role permissions evade administrator-configured AI tool governance controls for workflows operating in namespaces they do not own or administer. The flaw affects GitLab EE versions from 19.1 up to (but not including) 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1, while GitLab Community Edition and the patched releases are unaffected. Impact is confined to integrity of AI governance policy enforcement, with no confidentiality or availability loss, and no public exploit code has been identified at time of analysis; GitLab notes exploitation is only possible under certain conditions, making this a low-severity, low-priority issue despite being network-reachable.
Authenticated, low-privilege users in Foreman / Red Hat Satellite 6 that have the foreman_ansible plugin installed can bypass host-level visibility restrictions and pull the complete Ansible inventory - including host parameter values flagged as hidden - for hosts inside their own organization. The plugin's Ansible inventory API assembles its host list with an unscoped Host.where query, so the search filter attached to the caller's view_hosts permission is never applied, an incorrect-authorization (CWE-863) / IDOR-style defect. Rated CVSS 3.1 base 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), the issue requires valid credentials and a deliberately narrowed view_hosts filter, is confidentiality-only with no write or cross-organization reach, and no public exploit code identified at time of analysis.
Server-side request forgery in Chatwoot's Shopify OAuth integration allows an authenticated user to make the Chatwoot server issue attacker-influenced outbound HTTP requests through the OAuth callback handler in callbacks_controller.rb, affecting versions up to 4.17.1 (4.17.0 and 4.17.1 confirmed). The CVSS 4.0 vector carries PR:L, so a valid Chatwoot account is required, and the assessed impact is low (limited confidentiality effect with no scope change), consistent with a constrained or blind SSRF rather than arbitrary internal data retrieval. Publicly available exploit code exists and the issue was reported to the project without a vendor response, but there is no evidence of confirmed active exploitation (not in CISA KEV); the overall risk is low-priority.
DNS label length truncation in the Ruby resolv gem (versions before 0.7.2 and before 0.3.2) enables attacker-controlled hostnames to produce wire-format DNS queries naming a domain the attacker chose rather than the one the application intended. The flaw allows hostname allowlists and DNS egress controls to be silently bypassed - the validated string appears legitimate but the bytes transmitted to the recursive resolver describe a different name. No public exploit code has been identified at time of analysis, but the Scope:Changed CVSS rating reflects real spillover impact on DNS resolvers and audit logs beyond the vulnerable application itself.
Heap buffer overflow in the Ruby JSON gem's streaming generator (versions 2.9.0-2.19.8) enables reliable process crash via attacker-controlled serialized data. When applications invoke `JSON.dump(obj, io)` or `JSON::State#generate(obj, io)` to stream JSON to an IO object, the C-level generator can write past its internal buffer if the serialized object contains a string near 16 KB in size. Impact is confined to denial of service - reliable process termination - with no evidence of confidentiality or integrity impact. No public exploit code and no CISA KEV listing are identified at time of analysis; the CVSS score of 3.7 (Low) appropriately reflects the constrained attack conditions.
Buffer overflow in the Ruby zlib gem's Zlib::GzipReader allows remote or local attackers supplying crafted gzip data to corrupt process memory via the zstream_buffer_ungets function. Affected versions span all 3.0.x releases through 3.0.0, the 3.1.0-3.1.1 range, and 3.2.0-3.2.1, collectively covering a wide install base across Ruby 3.2 and 3.3 runtime environments. The vulnerability carries an EPSS of 0.04% (13th percentile) and is not listed in CISA KEV, indicating low current exploitation probability despite the memory-corruption class of the flaw.
Rack's Directory module fails to sanitize filenames when generating HTML directory listings, allowing attackers to craft files with javascript: scheme names that execute arbitrary code when clicked. Authenticated users or those with access to directories containing maliciously named files can trigger stored XSS attacks affecting other users viewing the directory index. Public exploit code exists for versions prior to 2.2.22, 3.1.20, and 3.2.5.
Mongoid's Criteria.from_hash method in Ruby can execute arbitrary code when processing specially crafted Hash objects, allowing authenticated attackers to achieve remote code execution on systems using vulnerable versions. The vulnerability requires valid credentials and network access but no user interaction, making it exploitable in environments where untrusted users have application access. No patch is currently available.
Faraday HTTP client library versions before 2.14.1 fail to properly validate protocol-relative URLs when merging user-supplied paths with base URLs, allowing attackers to redirect requests to arbitrary hosts via SSRF attacks. Applications that pass untrusted input to Faraday request methods like get() or post() are vulnerable to request hijacking. A patch is available in version 2.14.1 and later.
Spree versions up to 5.0.8 is affected by authorization bypass through user-controlled key (CVSS 5.3).
OpenC3 COSMOS (space mission control software, 5.0.0-6.10.1) has unauthenticated RCE through the JSON-RPC API. String parameters are evaluated as Ruby code via convert_to_value. Maximum CVSS 10.0 with scope change.
Spree e-commerce platform versions prior to 4.10.2, 5.0.7, 5.1.9, and 5.2.5 contain an authenticated insecure direct object reference vulnerability allowing logged-in users to access and retrieve address information belonging to other customers by manipulating address identifiers during order modification. Public exploit code exists for this vulnerability, which has been patched in the aforementioned versions.
CVE-2025-53623 is an arbitrary code execution vulnerability in the Job Iteration API's CsvEnumerator class affecting versions prior to 1.11.0. An unauthenticated remote attacker can execute arbitrary system commands by supplying malicious input to CSV file processing methods, particularly the count_of_rows_in_file method, potentially leading to complete system compromise. The vulnerability has a CVSS score of 8.1 indicating high severity with network-accessible attack vector and no privilege requirements.
A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
There is a buffer over-read in Ruby before 2.6.10, 2.7.x before 2.7.6, 3.x before 3.0.4, and 3.1.x before 3.1.2. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A double free was found in the Regexp compiler in Ruby 3.x before 3.0.4 and 3.1.x before 3.1.2. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Rated high severity (CVSS 7.4), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
In Ruby through 3.0 on Windows, a remote attacker can submit a crafted path when a Web application handles a parameter with TmpDir. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The REXML gem before 3.2.5 in Ruby before 2.6.7, 2.7.x before 2.7.3, and 3.x before 3.0.1 does not properly address XML round-trip issues. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Ruby through 2.5.8, 2.6.x through 2.6.6, and 2.7.x through 2.7.1. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
An issue was discovered in Ruby 2.5.x through 2.5.7, 2.6.x through 2.6.5, and 2.7.0. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
In Puma (RubyGem) before 4.3.2 and before 3.12.3, if an application using Puma allows untrusted input in a response header, an attacker can use newline characters (i.e. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows code injection if the first argument (aka the "command" argument) to Shell#[] or Shell#test in lib/shell.rb is untrusted data. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows HTTP Response Splitting. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
WEBrick::HTTPAuth::DigestAuth in Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 has a regular expression Denial of Service cause by looping/backtracking. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 mishandles path checking within File.fnmatch functions. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Ruby before 2.3.8, 2.4.x before 2.4.5, 2.5.x before 2.5.2, and 2.6.x before 2.6.0-preview3. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
An issue was discovered in the OpenSSL library in Ruby before 2.3.8, 2.4.x before 2.4.5, 2.5.x before 2.5.2, and 2.6.x before 2.6.0-preview3. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, the Dir.open, Dir.new, Dir.entries and Dir.empty? methods do not check NULL characters. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, the UNIXServer.open and UNIXSocket.open methods are not checked for null characters. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, an attacker controlling the unpacking format (similar to format string vulnerabilities) can. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, an attacker can pass a large HTTP request with a crafted header to WEBrick server or a crafted. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Directory traversal vulnerability in the Dir.mktmpdir method in the tmpdir library in Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1 might allow. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
The lazy_initialize function in lib/resolv.rb in Ruby through 2.4.3 uses Kernel#open, which might allow Command Injection attacks, as demonstrated by a Resolv::Hosts::new argument beginning with a. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Ruby before 2.4.3 allows Net::FTP command injection. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and EPSS exploitation probability 88.6%.
OS command injection in the image_optimizer Ruby gem versions 1.3.0 through 1.9.0 allows unauthenticated remote attackers to execute arbitrary shell commands with the privileges of the Ruby process by supplying an image path containing shell metacharacters such as ';'. The flaw is reachable only when the consuming application enables the 'identify' option (so that ImageOptimizer#identify_format runs) and the attacker controls the image path argument, typically through an attacker-chosen uploaded file name, which means real-world impact is bounded by the OS privileges of the Ruby/web worker process and by whether user-controlled filenames reach the gem. The CVSS 4.0 base score of 9.3 reflects high confidentiality, integrity and availability impact, and no public exploit identified at time of analysis; the included gist and VulnCheck advisory serve as the primary public technical disclosures.
Unbounded resource allocation in the Ruby bindings of Apache Thrift (versions before 0.25.0) lets unauthenticated remote clients exhaust server memory or CPU by sending Thrift messages whose declared structure or container sizes trigger excessive allocation while the service deserializes them. Only network-reachable services that actually accept and parse untrusted Thrift payloads through the Ruby bindings are exposed, and the impact is confined to availability, with no data disclosure or modification (C:N/I:N/A:H). The Apache Software Foundation has released 0.25.0 as the fix; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor rates this 8.2 (High) under CVSS 4.0, while our independent assessment also treats it as High severity but notes a higher attack complexity (AC:H in v3.1 terms) because the attacker must reach a service that parses untrusted Thrift messages.
Polynomial-time regular expression denial of service (CWE-1333) in the crmne/ruby_llm Ruby gem's Mistral provider capability matching allows unauthenticated remote attackers to exhaust CPU and stall requests by feeding a crafted model-identifier string into the modalities_for/capabilities_for code path, but only on hosts running Ruby 3.1.x, whose regex engine lacks the linear-time matching optimization. Availability is the sole impacted property (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), and the practical limiter is deployment context: the host application must route untrusted, attacker-influenced model IDs into this matching logic, since hardcoded or whitelisted model IDs neutralize the vector. CISA SSVC records Exploitation: none and there is no public exploit identified at time of analysis; an upstream fix exists in commit dd3c84812598def03d4aff77b5447c41d8f5c34e.
Polynomial-time regular expression denial-of-service in the crmne/ruby_llm library's <think>-tag response parsing can be triggered when a model response contains many unterminated <think> tags, driving excessive CPU consumption and delaying chat-completion processing. Only deployments pinned near commit fa6f279847d6d7027814539d9c0dfc3bbdfd2a83 and running on Ruby 3.1.x are affected, since Ruby 3.2+ regex engine optimizations mitigate the backtracking; RubyLLM exposes no direct network surface of its own, so an attacker must be able to shape the upstream LLM response (malicious/compromised model endpoint, prompt injection, or interception of the model API connection). No public exploit code has been identified at time of analysis, EPSS is 0.17% (5th percentile), and there is no CISA KEV listing; the consensus signal is a low-priority issue despite the vendor-assigned 7.5 score, with real impact limited to CPU consumption and processing delay in the request handling the response.
Server-side request forgery in Stringer, a self-hosted RSS reader, allows an authenticated low-privileged user to make the server issue arbitrary HTTP/HTTPS requests to internal network hosts, loopback services, and cloud metadata endpoints such as AWS IMDS at 169.254.169.254. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L, base 7.6) confirms a network-reachable, low-complexity attack requiring only an authenticated account - a barrier that collapses to near-anonymous when self-service signup (Setting::UserSignup) is enabled, since any visitor can register. Impact ranges from internal port and service scanning to theft of cloud IAM credentials when Stringer runs on a cloud instance with an attached role reachable via IMDSv1; there is no public exploit identified at time of analysis and no confirmed CISA KEV active exploitation, though the attack surface is trivial to exercise for anyone holding a valid session.
S/MIME signature spoofing in Zammad before 7.1.2 lets a remote, unauthenticated sender forge email that Zammad displays with the same 'validly signed' indicator as a genuine message, by presenting a self-made certificate whose subject name matches a certificate already stored for a real, previously trusted sender - no access to that sender's private key is required. Exploitation requires inbound S/MIME signature verification to be enabled on the target instance, a certificate to already exist for the impersonated sender, and a human (agent/user) to view and act on the forged ticket, so impact is confined to integrity/spoofing with no data disclosure or service disruption. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor fix exists in 7.1.2, and the flaw is genuine rather than inflated CVSS.
An authenticated broken-access-control flaw in Zammad's External Data Source feature lets any logged-in user - including a minimal customer-level account - read records that do not belong to them by supplying another record's numeric ID. The affected component builds a 'render context' from request parameters such as ticket_id, customer_id, user_id, group_id, and organization_id and passes it to the configured external system lookup without first checking whether the requesting user is permitted to see that record, so enumerable IDs leak ticket, user, group, and organization details. The issue affects Zammad versions prior to 7.1.2, where the vendor-released patch (7.1.2) adds an explicit authorization check; no public exploit code or confirmed active exploitation was identified at time of analysis.
Zammad's SSO auto-linking logic can be abused to take over any existing local account, including agent and administrator accounts, because it binds an incoming third-party identity to a local user purely by matching the email address the identity provider reports. An unauthenticated remote attacker only needs to control one identity at any provider configured on the target instance - with Zammad's default multi-tenant Microsoft 365 /common app registration, any Azure AD tenant qualifies - set that identity's email to the victim's address, then authenticate and be logged in as that victim without ever knowing their local password. Exploitation requires the 'Automatic account link on initial logon' setting to be enabled and at least one SSO provider configured; no public exploit code has been identified at time of analysis and the issue is confirmed fixed in Zammad 7.1.2.
Authenticated administrators of the Zammad helpdesk platform (versions prior to 7.1.2) can achieve remote code execution on the Zammad server by injecting specially crafted text into an AI Agent configuration field that bypasses the application's ERB sanitizer. Because the pre-7.1.2 sanitizer used Ruby's `.sub` and escaped only the first `<%` opener, an attacker with AI Agent create/edit permissions can smuggle a nested ERB tag (e.g. `<%<%= ... %>`) that executes automatically the next time the affected agent processes a ticket, with no interaction from other users required; this yields full read/write/delete access to data on the host (VC:H/VI:H/VA:H). The flaw is a genuine remote code execution issue, not a mislabeled availability problem, and it requires admin-level privileges (PR:H) plus the optional AI Agent feature being in active use; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor fix ships in Zammad 7.1.2 (GHSA-gp3x-9xm8-rcj6).
Unauthenticated denial of service in Zammad prior to 7.0.2 allows any remote attacker who can reach the host to tie up a Puma request worker for roughly 115 seconds per request by POSTing to /api/v1/import/otrs/import_check. The import_check and import_status actions are missing the setup_done_response guard that other actions in the same controller enforce, so they run against fully set-up production instances, where the code enters a retry loop against a blank OTRS endpoint and sleeps 30 s then 45 s between attempts. Each request costs the attacker almost nothing, so a sustained rate of just a few requests per second saturates the worker pool and keeps the instance unavailable as long as the traffic continues; no account, valid import configuration, or target knowledge beyond the hostname is required, and the CSRF token is trivially harvested from any prior GET response. This is a genuine availability risk that is trivial to trigger, but no public exploit code or confirmed active exploitation has been identified at time of analysis.
Improper privilege management in Zammad helpdesk/customer support systems allows an attacker holding a valid but deliberately restricted API token to create new administrator accounts, inheriting the latent authorization authority of the token's parent account instead of honoring the token's granular scope. This affects all Zammad releases prior to 7.0.2 and 7.1.0, and exploitation is authenticated (CVSS PR:L) since a scoped token must already be held, though no user interaction is required and the vector is network-reachable; success grants full access to tickets, customers, and configuration and effectively hands the attacker complete control of the instance. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), but the independent assessment rates it a genuine high-priority privilege-escalation flaw rather than a high-CVSS-but-low-risk case, and EPSS-style risk is elevated by the trivial post-exploitation payoff.
Stored cross-site scripting in Zammad prior to 7.0.1 lets an authenticated low-privilege user persist arbitrary HTML markup and JavaScript event handlers inside a ticket title through the normal ticket-creation workflow, because the title is stored without sanitization and later rendered unescaped. The payload fires when a victim - typically a support agent or administrator with an active session - opens the affected ticket or receives a notification, escalation or reminder email that interpolates the title, yielding script execution in the victim's browser context. No public exploit code has been identified at time of analysis, the flaw is not listed as actively exploited, and exploitation requires both an authenticated account with ticket-creation rights and victim interaction; Zammad 7.0.1 contains the vendor fix.
An authenticated GitLab EE user can read sensitive CI/CD variable values from debug-mode job traces via the Duo AI troubleshooting feature because of a missing authorization check (CWE-862). Affected versions are GitLab EE 18.7 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1. Exploitation is gated behind authentication and requires the non-default combination of CI_DEBUG_TRACE debug tracing and the Duo AI feature, and no public exploit code has been identified at time of analysis; this is a moderate-priority issue rather than a critical one.
Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in user, including one with only low-tier permissions, execute arbitrary Ruby and Python code on the COSMOS server and its per-target decom microservices. COSMOS reads configuration from a user-writable overlay (targets_modified/) before its read-only targets/ tree and then executes that content - rendering it as ERB, eval-ing GENERIC_READ/WRITE_CONVERSION blocks, or require-ing Script Runner procedure files - so an attacker who can write to the overlay via the screen-save or storage-upload endpoints achieves code execution as the openc3 user, which holds Redis and object-store credentials and sits on the internal service network. A working proof-of-concept is published in the vendor GitHub advisory, and the vendor has released 7.3.0 as the fix; no confirmed active exploitation (CISA KEV) has been reported. Reachability is limited on default single-host installs because the shipped docker-compose binds Traefik to 127.0.0.1:2900, so exploitation is realistic on multi-user deployments that expose the web port.
Authenticated OS command injection in OpenC3 COSMOS 5.12.0 through 7.2.1 allows a user with a valid session to run arbitrary operating-system commands as the openc3 service user by writing shell metacharacters into the pypi_url setting and then installing a plugin that carries Python dependency metadata. The injected value is interpolated into a shell backtick inside PluginModel.install_phase2, so commands execute with access to the service's Redis and bucket storage credentials; in the open-source edition any authenticated user can reach both the setting-write and plugin-install operations, whereas the Enterprise edition requires the administrator role, and the vendor has fixed the issue in 7.3.0. There is no CISA KEV listing or confirmed in-the-wild exploitation, but the public vendor advisory GHSA-vp3w-52v9-q57f includes confirmed end-to-end proof-of-concept steps, and the independent assessment rates this as a genuine high-priority issue rather than CVSS inflation.
Code injection in Mongoid allows unauthenticated attackers who can influence a query argument to execute arbitrary JavaScript in the MongoDB server via a string-typed query criterion, leading to disclosure of stored field values, unintended document selection for writes, and reduced database performance. The vulnerability affects Mongoid versions 8.0.0 through 8.0.12, 8.1.0 through 8.1.12, 9.0.0 through 9.0.11, and 9.1.0, but exploitation requires the application to pass externally influenced string criteria to the query builder and the MongoDB deployment to permit server-side JavaScript evaluation. No public exploit identified at time of analysis.
Unauthenticated, remote query-operator injection in Mongoid - the official MongoDB object-document mapper for Ruby - allows an attacker to shape how MongoDB evaluates a query whenever an application forwards externally supplied filter parameters straight into Mongoid query-building methods without whitelisting allowed operators. Successful abuse can disclose stored field values (for example through $ne, $gt or $regex-style filter logic used for blind extraction) and, because operators such as $regex or $where can force expensive scans, can degrade database performance. The impact is conditional: the vendor's CVSS 4.0 vector carries AT:P (attack requirements present) and our assessment uses AC:H, because exploitation depends entirely on the downstream application's query-construction pattern rather than on a Mongoid setting. No public exploit code was identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided. CVSS 4.0 base is 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L) and our independent CVSS 3.1 assessment is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L, i.e. high confidentiality impact with a limited availability effect and no integrity impact.
CPU exhaustion in MongoDB's Mongoid Ruby ODM allows an unauthenticated remote party to render an embedding application unresponsive by supplying crafted text that lands inside a pattern-matching query condition Mongoid evaluates in memory against an embedded association, triggering catastrophic regex backtracking (CWE-1333, ReDoS). The impact is availability-only: the affected Ruby application process burns CPU and stops responding, with no confidentiality or integrity effect. No public exploit code has been identified at time of analysis, and reachability depends on a specific application coding pattern, which is why the independent assessment applies AC:H and treats deployments that never route untrusted input into regex conditions on embedded documents as out of scope (the CNA's CVSS 4.0 vector rates it 8.7 with AC:L, a more aggressive reading than the assessed CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).
Data disclosure and permanent record deletion in Mongoid can be triggered by an unauthenticated remote attacker when an application passes an externally supplied field name to certain in-memory query methods for embedded documents, exploiting an unsafe reflection weakness (CWE-470). The vendor CVSS 4.0 base score of 9.2 reflects the network vector and high impact across confidentiality, integrity, and availability, though the attack requires a developer-dependent data flow (AT:P) where untrusted input reaches a field name parameter. No public exploit code or active exploitation has been identified at time of analysis, and affected/fixed versions remain unconfirmed due to an unbounded CPE (mongoid:*).
Silent, warning-free failure of encryption-configuration generation in the Mongoid object-document mapper causes fields that an application explicitly declared for client-side field-level encryption (CSFLE) to be written to MongoDB as cleartext, allowing any party with ordinary read access to the database - a DBA, a read replica, a backup, or a lower-privilege account with query rights - to read values that were intended to be protected from them. Only applications built on Mongoid that use MongoDB CSFLE and declare fields for encryption are affected; the CVSS vectors (the supplied 4.0 vector with PR:L and the independently assessed 3.1 vector with PR:L) indicate the attacker requires some existing privilege, consistent with the assessed precondition of ordinary database read access rather than an unauthenticated remote path. No public exploit code has been identified at time of analysis, and this is assessed as a genuine but conditional data-protection failure rather than an actively exploited priority.
Mongoid can silently persist values in readable form that applications intended to encrypt, because its client-side field-level encryption (CSFLE) schema generation omits encryption rules for fields declared on embedded models - the MongoDB driver then writes those values unencrypted with no error or warning. The exposure is limited to applications that both enable CSFLE and declare encrypted fields on embedded documents (top-level fields are not implicated), and to parties who already hold read access to the database, a backup, or the underlying on-disk data files; there is no write, integrity, or availability impact and no remote code execution. Data-level risk is real but bounded: no public exploit code identified at time of analysis, no confirmed active exploitation, and the reported CVSS 4.0 base score of 7.1 is consistent with the independent CVSS 3.1 assessment of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
Unsafe reflection (CWE-470) in Mongoid's document persistence layer allows a crafted key to be reflected into an internal method invocation instead of the intended array-field update, which can delete stored records and render the embedding application unresponsive. The affected component is Mongoid, MongoDB's Ruby object-document mapper; the CPE record (cpe:2.3:a:mongodb_inc.:mongoid:*:*:*:*:*:*:*) carries no version bounds, so the vendor has not published a bounded version range, and exposure applies to any embedding application that forwards unauthenticated, attacker-controlled keys directly into an array-field update. The CVSS 4.0 vector marks this dependency as AT:P (Attack Requirements: Present), meaning Mongoid is not exploitable in isolation, but where that non-default coding pattern exists there is no authentication or user-interaction barrier (PR:N, UI:N/A:H). Impact is integrity and availability only (VI:H/VA:H, VC:N), and no public exploit code has been identified at time of analysis.
Insecure direct object reference in Mongoid's nested-attributes handling lets an authenticated user with basic application privileges supply another user's record identifier, causing Mongoid to look up that record outside ownership or tenant scoping and then update and link it to the requester's own record-resulting in unintended disclosure and unauthorized modification of data. Exploitation is limited to applications that use accept_nested_attributes_for on ownership- or tenant-scoped associations and rely on Mongoid to enforce scoping; no public exploit identified at time of analysis, and no confirmed affected or fixed versions because the only reference is an unbounded MongoDB Jira advisory with a wildcard CPE.
HTTP request smuggling via inconsistent request framing in Puma's native http11_parser (reported range Puma 5.0.0 through 8.0.3) allows a remote, unauthenticated attacker to desynchronize request boundaries between Puma and an upstream HTTP intermediary, enabling request hijacking, cache poisoning, or bypass of front-end access controls; the description's claim of arbitrary code execution is unverified and inconsistent with CWE-444. Exploitation is deployment-dependent: it requires a reverse proxy, CDN, or load balancer whose parsing of ambiguous Content-Length/Transfer-Encoding framing diverges from Puma's, which is why our independent assessment rates it AV:N/AC:H/PR:N/UI:N/S:C rather than the published 9.1. Risk signals are weak and conflicting - EPSS is 0.17% (6th percentile), there is no CISA KEV listing and no confirmed public exploit code, and the only third-party reference is an unverified GitHub issue - so raw severity should be discounted.
Unbounded memory exhaustion in Ruby's resolv gem (before 0.7.2) allows an attacker controlling DNS responses to permanently grow a target process's memory without limit, eventually crashing the service. The root cause is that Resolv::DNS::Resource.get_class and related methods register a new Ruby class as a constant for each unknown DNS resource record type/class pair encountered, preventing garbage collection for the lifetime of the process. Because resolv is a default Ruby gem requiring no installation step, any plain Ruby installation performing DNS resolution - web services, workers, CLI tools - is exposed without opt-in configuration, and no public exploit has been identified at time of analysis.
Heap-use-after-free in the Ruby json gem's native C extension (versions 2.20.0 through 2.21.1) allows an unauthenticated remote attacker to crash the Ruby process by supplying a crafted truncated JSON stream with duplicate object keys to any application using JSON::ResumableParser. The root cause is that the parser's input buffer is freed without resetting the state.start, state.cursor, and state.end pointers, which are subsequently dereferenced when partial_value processes the duplicate-key warning path via cursor_position, producing a heap-use-after-free confirmed by AddressSanitizer and a native SIGSEGV on official RubyGem releases. Impact is limited to availability - no code execution or information disclosure is claimed - and no public exploit code has been identified at time of analysis, though a private end-to-end TCP proof-of-concept was submitted with the advisory.
Use-after-free in Ruby 4.x (before 4.0.5) lets remote attackers who can manipulate DNS response timing crash applications calling Addrinfo.getaddrinfo with a timeout: option or Socket.tcp with resolv_timeout:. The flaw lives in the pthread-based getaddrinfo timeout handler (rb_getaddrinfo in ext/socket/raddrinfo.c) and, while reliably exploitable for denial of service, also raises a theoretical possibility of memory-corruption-based code execution. No public exploit identified at time of analysis.
Remote code execution in Ruby ERB library via unsafe deserialization allows unauthenticated attackers to execute arbitrary code by exploiting incomplete protection in Marshal.load workflows. While ERB 2.2.0+ added guards to prevent code execution during deserialization in result() and run() methods, the def_module(), def_method(), and def_class() methods remained unprotected, enabling attackers to bypass the @_init safeguard. Exploitation requires high complexity (AV:N/AC:H) as applications must deserialize untrusted Marshal data with ERB loaded. No EPSS or KEV data available; exploitation likelihood depends on prevalence of unsafe Marshal.load patterns in Ruby codebases.
Remote code execution in Manyfold prior to version 0.133.0 allows authenticated users to execute arbitrary commands by uploading a ZIP archive with specially crafted filenames containing shell metacharacters that are passed unsanitized to Ruby backtick execution. The vulnerability affects the model render generation feature and requires an attacker to be logged in, with public exploit code currently available. A patch is available in version 0.133.0 and later.
Stored XSS in Bugsink error tracking tool before 2.0.13 allows unauthenticated attackers to inject persistent scripts through error event submissions. PoC and patch available.
Use After Free vulnerability in Apache Arrow C++. This issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. [CVSS 7.0 HIGH]
Spree Commerce's guest checkout feature contains an insecure direct object reference (IDOR) flaw that allows unauthenticated attackers to access other customers' personally identifiable information by manipulating address parameters during transaction processing. Public exploit code exists for this vulnerability, which affects all guest checkout flows across multiple Spree versions. Patches are available for versions 4.10.3, 5.0.8, 5.1.10, 5.2.7, and 5.3.2.
Spree versions up to 4.10.2 is affected by authorization bypass through user-controlled key (CVSS 7.5).
Razorpay IFSC Ruby gem through version 2.0.62 is affected by a server-side request forgery (SSRF) vulnerability. Unauthenticated remote attackers can supply a crafted IFSC code to IFSC.find or IFSC#get - such as a network-path reference (//evil.host) or an absolute URI - that Ruby's URI.join resolves as a new host, redirecting API requests to internal or attacker-chosen hosts and returning parsed response fields. Exploitation requires the consuming application to pass untrusted input directly to these methods; impact is limited to low confidentiality (CVSS 4.0 base 6.9) with no write or availability effect, and no public exploit has been identified at time of analysis.
Cross-origin credential leakage in the Mechanize Ruby library (versions prior to 2.14.1) allows attackers who control a redirect target to capture bearer tokens, session cookies, Proxy-Authorization credentials, or Cookie2 values that the calling application supplied through Mechanize#request_headers= or the per-request headers argument. The flaw is conditional: it only triggers when an application actually sets credentials via those header APIs and a response issues a cross-origin HTTP redirect (or a cross-origin meta refresh), so same-origin redirects are unaffected and credentials managed through Mechanize#cookie_jar or Mechanize::HTTP::AuthStore are explicitly out of scope; there is no public exploit identified at time of analysis. Because the attacker must influence the redirect destination rather than merely reach the service, this is a genuine but conditional information-disclosure issue (CWE-200) rather than a mass-exploitation priority.
Credential-header leakage in the Ruby Mechanize gem before 2.14.1 allows sensitive headers to be forwarded to a lower-trust destination during redirect following, because Mechanize::HTTP::Agent#response_redirect considered a redirect same-origin whenever the host matched, without comparing scheme or port. A same-host HTTPS-to-HTTP downgrade can put caller-supplied Authorization (or Proxy-Authorization) and Cookie (or Cookie2) headers on the wire in cleartext, and a same-host redirect to a different port can deliver a caller-supplied Cookie to an unrelated service listening there. Per the assessed vector (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) the impact is confidentiality-only with no integrity or availability effect, and no public exploit was identified at time of analysis; the practical risk is limited because the consuming application must explicitly inject its own credential headers and an attacker must control or man-in-the-middle the redirect response, while cookies held in Mechanize#cookie_jar are scoped correctly and are not leaked. Vendor-released patch: 2.14.1.
Credential leakage in the Ruby Mechanize library before 2.14.1 lets an attacker who controls page content encountered during a crawl capture bearer tokens or session cookies, because a cross-origin meta refresh caused Mechanize::HTTP::Agent#response_follow_meta_refresh to reapply the caller's global default headers to the refresh request. Exploitation is conditional and rated AC:H: Mechanize#follow_meta_refresh must be explicitly enabled (it defaults to false), the caller must have placed sensitive credentials in the agent-wide default headers via Mechanize#request_headers=, and the attacker must be able to serve attacker-controlled markup to the crawl, though the request itself is unauthenticated (PR:N) and requires no user interaction (UI:N). There is no KEV entry, no public exploit identified at time of analysis, and no EPSS score supplied; the vendor-released fix is Mechanize 2.14.1, where cross-origin meta refreshes now discard credential and cookie headers under the same origin rules as HTTP redirects.
Object-level authorization bypass in owen2345 Camaleon CMS through 2.9.2 lets an authenticated user who holds only the media-library permission (`:manage, :media`) overwrite another user's avatar by calling the admin media crop endpoint with the `saved_avatar` parameter set to a victim's user ID. The crop action reaches the same avatar meta write that `UsersController#update` protects with `:manage, :users`, but enforces only the media permission, so the media library becomes a side door into profile editing; post-PR-#1267 the target is scoped to `current_site.users`, limiting the bypass to same-site, cross-user writes rather than cross-tenant ones. Publicly available exploit code exists (CVSS 4.0 vector carries E:P), and the vendor has released a fix in 2.9.3; the exposure is limited to profile-meta tampering with no access to passwords, credentials, or confidential data, so the assessed risk is genuinely low. No confirmed active exploitation (CISA KEV) was identified at time of analysis.
Incomplete masking of Microsoft Graph bearer tokens in Zammad's HTTP log allows an authenticated Zammad administrator with Microsoft Graph channel access to read the payload and signature segments of a still-valid mailbox access token from stored log entries, exposing sensitive JWT claims such as account scope, tenant and timing that could assist in reconstructing the full token while it remains valid. Only Zammad deployments older than 7.1.2 that use a Microsoft Graph email channel and that have recorded a failed Graph API request are affected; the flaw is gated by high administrative privilege and is not remotely reachable by unauthenticated users, and no public exploit identified at time of analysis. The vendor-released patch is Zammad 7.1.2, and independent assessment rates this as a low-severity information-disclosure issue consistent with the CVSS 4.0 score of 5.1.
Improper URL sanitization in Zammad's inbound-email/ticket HTML scrubber lets an attacker embed traversal-laden <img src> or srcset URLs that survive the remote-URL check; when an authenticated agent simply views the message, the browser resolves the URL to a same-origin Zammad API endpoint and issues the request with the agent's session cookie, producing disruptive state changes such as forced logout with no further interaction. The attacker needs no Zammad account (the payload is delivered as ordinary inbound email or ticket content), but the effect only triggers on agent view (UI:P) and is confined to low-integrity/low-availability same-origin calls rather than data exfiltration. Exploitation status: no public exploit identified at time of analysis; a vendor-released patch is available in Zammad 7.1.2.
An improper PGP signature verification flaw in Zammad 7.0.3 and 7.1.1 lets a remote, unauthenticated sender have an inbound email article saved with a successful 'Good signature' status even though the displayed message body is not actually covered by that signature, misleading agents who trust the indicator. Exploitation requires the inbound PGP secure-mailing feature to be configured with a registered/trusted sender key and possession of a genuine opaque ('-----BEGIN PGP MESSAGE-----') signed message from that sender, which is replayed while the displayed body is swapped; an agent must open the article and rely on the signature indicator (UI:R). The impact is limited to integrity of the displayed content, not confidentiality or availability, and no public exploit has been identified at time of analysis. Zammad fixed the issue in version 7.1.2.
Zammad 7.0.3 and 7.1.1 return stored LDAP and Exchange integration credentials in cleartext through the integration administration API, allowing an authenticated administrator to read secrets the UI is supposed to mask. Because the vulnerable endpoints are the import 'job_try' responses, a user holding full admin rights - and only such a user - can recover the LDAP bind password, the Exchange EWS password, or a stored OAuth access token, plus raw request parameters that leak into the persisted ImportJob payload. Per the supplied vector the issue requires high privileges (PR:H) and results in confidentiality impact only, with no code execution or data modification; there is no public exploit identified at time of analysis, and the vendor-released fix is Zammad 7.1.2.
Stored cross-site scripting in Zammad's Knowledge Base video widget lets an authenticated user who holds Knowledge Base editing rights for a category publish an answer whose crafted video 'id' value breaks out of the generated <iframe> attribute context and injects arbitrary HTML; when a second, more privileged user who can switch between user sessions opens that published answer, the injected markup silently fires a request to Zammad's session-switching endpoint and forces the victim's session onto an account chosen by the attacker. Exploitation requires two distinct privileges (a Knowledge Base editor on the attacker side and session-switch/impersonation permission on the victim side) plus the victim simply viewing the published answer, and no public exploit code has been identified at time of analysis. The flaw is tracked as CWE-79 and is fixed in Zammad 7.1.2; the circumstances make this a genuine but conditionally gated stored XSS that chains into a forced session-switch account takeover rather than a raw remote flaw.
Authenticated users of the Zammad helpdesk platform prior to 7.1.2 can read the tag names assigned to any ticket, including tickets they are not authorized to view, because the tag-list/autocomplete endpoint enforced no ticket-scoped authorization. Any account that can authenticate - including low-privilege customers or limited agents - can query the endpoint and, since ticket IDs are sequential integers, enumerate ticket tags in bulk to infer internal categorization and potentially sensitive labels. The exposure is confidentiality-only (no data modification or denial of service), no public exploit code has been identified at time of analysis, and the flaw is fully corrected in Zammad 7.1.2, where the endpoint is restricted to ticket.agent, admin.tag, and knowledge_base.editor permissions.
Information disclosure in the Zammad helpdesk/customer support system versions prior to 7.1.2 allows a remote, unauthenticated party to embed a tracking pixel that evades the built-in HTML sanitizer, so that when an agent views the crafted ticket or email the recipient's browser silently loads an external image and leaks read-receipt metadata such as when and by whom the ticket was opened. Exploitation requires the recipient to open the article in a browser (CVSS 4.0 base score 5.3; independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and impact is bounded to open-time and viewer-fingerprint disclosure rather than ticket contents, credentials, or code execution. No public exploit code has been identified at time of analysis and the CVE is not in CISA KEV; the vendor-released fix is version 7.1.2.
Zammad helpdesk versions prior to 7.1.2 let an authenticated channel administrator read attachments outside their authorized groups by embedding an existing attachment ID in an email signature. The signature processor copies the referenced attachment into a signature-owned record and then serves it based on the copy's ownership rather than the original ticket or knowledge-base object, creating an authorization bypass (CWE-639). The vendor fixed this in 7.1.2; exploitation requires one of the channel-admin permissions and no public exploit code has been identified at time of analysis.
Zammad helpdesk instances prior to 7.1.2 expose a legacy destroy_form action on AttachmentsController that deletes temporary UploadCache store records using only a caller-supplied form_id and performs no ownership verification (CWE-862), so an authenticated user who knows another user's pending-upload UUID can silently wipe that user's in-progress attachments before the ticket or article is submitted. Exploitation requires a valid account on the instance plus knowledge of the victim's non-enumerable form_id UUID and only affects files still in the transient pre-submission cache, which is why the base score is a low 2.3 under CVSS 4.0 (equivalently AV:N/AC:H/PR:L/UI:N/C:N/I:L/A:L on CVSS 3.1). No public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in Zammad 7.1.2.
Broken access control in Zammad's GraphQL API allows an authenticated user to read taskbar item data - transient session state that can include auto-saved ticket drafts - belonging to another user by supplying that user's taskbar identifier. The flaw affects Zammad versions prior to 7.0.2 and was addressed upstream in the 7.0.2 release, which adds the missing authorization checks. Exploitation requires a valid low-privilege account (authenticated) plus knowledge or enumeration of the target taskbar item ID; there is no public exploit code identified at time of analysis, and impact is limited to a single victim's taskbar item per request.
Session-termination vulnerability in Zammad helpdesk/customer-support deployments running versions prior to 7.0.2: the HTML sanitizer fails to strip same-origin Zammad API paths from <img> src and srcset attributes, so crafted ticket HTML can reference endpoints such as /api/v1/signout, /api/v1/sessions/switch/N, /api/v1/sessions/switch_back, or /api/v1/getting_started/auto_wizard/<token>, causing the viewing agent's session to be terminated or switched when the ticket is rendered. The attack is unauthenticated per the CVSS 4.0 vector (PR:N) and can be delivered via inbound-email-created tickets, but it requires a second user to view the crafted ticket (UI:P) and is bounded to session availability with no data disclosure or code execution. CVSS 4.0 scores it 5.3 (MEDIUM) and an independent assessment rates it CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L; no public exploit code or CISA KEV entry was identified at time of analysis, and the vendor released 7.0.2 with an allowlist restricting /api/ image sources to attachment endpoints.
Information disclosure in Zammad lets any sender capable of emailing a helpdesk instance embed an arbitrary external URL in the srcset attribute of an image, so that the agent's browser silently fetches attacker-controlled content the moment the ticket is viewed. Zammad's HtmlSanitizer::Strict blocked external URLs in the src attribute but left the equally allowlisted srcset attribute unchecked, leaking the agent's IP address, User-Agent, Referer and the precise viewing time to the sender. All releases before 7.0.2, and 7.1.x releases before 7.1.0, are affected; fixes are available in 7.0.2 and 7.1.0, and no public exploit code was identified at time of analysis. The impact is a privacy/tracking leak rather than code execution or data theft, and it depends on an agent actually opening the crafted ticket in a browser that honours srcset.
Server-side request forgery in Zammad (versions prior to 7.0.2) lets a user who controls their own profile at a connected federated identity provider (OAuth, OIDC, or SAML) make the helpdesk server issue outbound HTTP requests to attacker-chosen addresses, including internal network locations, by supplying a crafted profile image URL. Because the fetch is blind, the attacker infers internal reachability only from differences in response timing and error patterns, and each probe can block a worker process for several seconds, producing a minor availability side effect. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited; exploitation requires a non-default deployment where federated login is configured and the attacker can edit their provider-side profile image URL. Fixed in Zammad 7.0.2.
Missing per-ticket authorization in Zammad's GitHub and GitLab issue-tracker integration endpoints prior to 7.0.2 lets any authenticated agent - including one with no tickets assigned - enumerate ticket IDs and read the titles, statuses, labels, and URLs of external GitHub/GitLab issues linked to tickets they are not permitted to see. The flaw carries CVSS 5.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting a low-confidentiality-impact disclosure confined to authenticated internal users, and yields nothing on instances where the GitHub/GitLab integration is not configured or no tickets carry linked issues. No public exploit code or active exploitation has been identified at time of analysis; the vendor shipped Zammad 7.0.2 as the fix.
Information disclosure in the Zammad helpdesk knowledge base lets an authenticated user who holds the knowledge_base.editor permission in at least one category see answer titles and updated_at timestamps belonging to categories where they have no editor rights, exposed through the global quick search. The leak only occurs in deployments that use granular, per-category permission assignments with differing editor roles; category names are not exposed and opening a leaked answer returns 'Page not found,' so no answer body content is accessible. Exploitation requires a valid authenticated account with the editor permission (PR:L/H depending on the scoring system) and is rated low severity (CVSS 4.0 base 2.1), with no public exploit identified at time of analysis.
Merge request authorship spoofing in GitLab CE/EE 19.1 through 19.4.0 lets an authenticated user who can perform a Direct Transfer import attribute merge request content to arbitrary existing users on the target instance. Exploitation requires a valid account with the ability to run a direct-transfer migration and depends on a timing/state condition in ephemeral cache handling, so it is not deterministic; the assessed impact is integrity-only with no confidentiality or availability effect, and no public exploit identified at time of analysis. GitLab has shipped fixed releases 19.2.7, 19.3.3, and 19.4.1.
Authentication bypass in GitLab Enterprise Edition lets an authenticated user holding developer-role permissions evade administrator-configured AI tool governance controls for workflows operating in namespaces they do not own or administer. The flaw affects GitLab EE versions from 19.1 up to (but not including) 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1, while GitLab Community Edition and the patched releases are unaffected. Impact is confined to integrity of AI governance policy enforcement, with no confidentiality or availability loss, and no public exploit code has been identified at time of analysis; GitLab notes exploitation is only possible under certain conditions, making this a low-severity, low-priority issue despite being network-reachable.
Authenticated, low-privilege users in Foreman / Red Hat Satellite 6 that have the foreman_ansible plugin installed can bypass host-level visibility restrictions and pull the complete Ansible inventory - including host parameter values flagged as hidden - for hosts inside their own organization. The plugin's Ansible inventory API assembles its host list with an unscoped Host.where query, so the search filter attached to the caller's view_hosts permission is never applied, an incorrect-authorization (CWE-863) / IDOR-style defect. Rated CVSS 3.1 base 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), the issue requires valid credentials and a deliberately narrowed view_hosts filter, is confidentiality-only with no write or cross-organization reach, and no public exploit code identified at time of analysis.
Server-side request forgery in Chatwoot's Shopify OAuth integration allows an authenticated user to make the Chatwoot server issue attacker-influenced outbound HTTP requests through the OAuth callback handler in callbacks_controller.rb, affecting versions up to 4.17.1 (4.17.0 and 4.17.1 confirmed). The CVSS 4.0 vector carries PR:L, so a valid Chatwoot account is required, and the assessed impact is low (limited confidentiality effect with no scope change), consistent with a constrained or blind SSRF rather than arbitrary internal data retrieval. Publicly available exploit code exists and the issue was reported to the project without a vendor response, but there is no evidence of confirmed active exploitation (not in CISA KEV); the overall risk is low-priority.
DNS label length truncation in the Ruby resolv gem (versions before 0.7.2 and before 0.3.2) enables attacker-controlled hostnames to produce wire-format DNS queries naming a domain the attacker chose rather than the one the application intended. The flaw allows hostname allowlists and DNS egress controls to be silently bypassed - the validated string appears legitimate but the bytes transmitted to the recursive resolver describe a different name. No public exploit code has been identified at time of analysis, but the Scope:Changed CVSS rating reflects real spillover impact on DNS resolvers and audit logs beyond the vulnerable application itself.
Heap buffer overflow in the Ruby JSON gem's streaming generator (versions 2.9.0-2.19.8) enables reliable process crash via attacker-controlled serialized data. When applications invoke `JSON.dump(obj, io)` or `JSON::State#generate(obj, io)` to stream JSON to an IO object, the C-level generator can write past its internal buffer if the serialized object contains a string near 16 KB in size. Impact is confined to denial of service - reliable process termination - with no evidence of confidentiality or integrity impact. No public exploit code and no CISA KEV listing are identified at time of analysis; the CVSS score of 3.7 (Low) appropriately reflects the constrained attack conditions.
Buffer overflow in the Ruby zlib gem's Zlib::GzipReader allows remote or local attackers supplying crafted gzip data to corrupt process memory via the zstream_buffer_ungets function. Affected versions span all 3.0.x releases through 3.0.0, the 3.1.0-3.1.1 range, and 3.2.0-3.2.1, collectively covering a wide install base across Ruby 3.2 and 3.3 runtime environments. The vulnerability carries an EPSS of 0.04% (13th percentile) and is not listed in CISA KEV, indicating low current exploitation probability despite the memory-corruption class of the flaw.
Rack's Directory module fails to sanitize filenames when generating HTML directory listings, allowing attackers to craft files with javascript: scheme names that execute arbitrary code when clicked. Authenticated users or those with access to directories containing maliciously named files can trigger stored XSS attacks affecting other users viewing the directory index. Public exploit code exists for versions prior to 2.2.22, 3.1.20, and 3.2.5.
Mongoid's Criteria.from_hash method in Ruby can execute arbitrary code when processing specially crafted Hash objects, allowing authenticated attackers to achieve remote code execution on systems using vulnerable versions. The vulnerability requires valid credentials and network access but no user interaction, making it exploitable in environments where untrusted users have application access. No patch is currently available.
Faraday HTTP client library versions before 2.14.1 fail to properly validate protocol-relative URLs when merging user-supplied paths with base URLs, allowing attackers to redirect requests to arbitrary hosts via SSRF attacks. Applications that pass untrusted input to Faraday request methods like get() or post() are vulnerable to request hijacking. A patch is available in version 2.14.1 and later.
Spree versions up to 5.0.8 is affected by authorization bypass through user-controlled key (CVSS 5.3).
OpenC3 COSMOS (space mission control software, 5.0.0-6.10.1) has unauthenticated RCE through the JSON-RPC API. String parameters are evaluated as Ruby code via convert_to_value. Maximum CVSS 10.0 with scope change.
Spree e-commerce platform versions prior to 4.10.2, 5.0.7, 5.1.9, and 5.2.5 contain an authenticated insecure direct object reference vulnerability allowing logged-in users to access and retrieve address information belonging to other customers by manipulating address identifiers during order modification. Public exploit code exists for this vulnerability, which has been patched in the aforementioned versions.
CVE-2025-53623 is an arbitrary code execution vulnerability in the Job Iteration API's CsvEnumerator class affecting versions prior to 1.11.0. An unauthenticated remote attacker can execute arbitrary system commands by supplying malicious input to CSV file processing methods, particularly the count_of_rows_in_file method, potentially leading to complete system compromise. The vulnerability has a CVSS score of 8.1 indicating high severity with network-accessible attack vector and no privilege requirements.
A ReDoS issue was discovered in the Time component through 0.2.1 in Ruby through 3.2.1. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
There is a buffer over-read in Ruby before 2.6.10, 2.7.x before 2.7.6, 3.x before 3.0.4, and 3.1.x before 3.1.2. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
A double free was found in the Regexp compiler in Ruby 3.x before 3.0.4 and 3.1.x before 3.1.2. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Rated high severity (CVSS 7.4), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
In Ruby through 3.0 on Windows, a remote attacker can submit a crafted path when a Web application handles a parameter with TmpDir. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The REXML gem before 3.2.5 in Ruby before 2.6.7, 2.7.x before 2.7.3, and 3.x before 3.0.1 does not properly address XML round-trip issues. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Ruby through 2.5.8, 2.6.x through 2.6.6, and 2.7.x through 2.7.1. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
An issue was discovered in Ruby 2.5.x through 2.5.7, 2.6.x through 2.6.5, and 2.7.0. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
In Puma (RubyGem) before 4.3.2 and before 3.12.3, if an application using Puma allows untrusted input in a response header, an attacker can use newline characters (i.e. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows code injection if the first argument (aka the "command" argument) to Shell#[] or Shell#test in lib/shell.rb is untrusted data. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows HTTP Response Splitting. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
WEBrick::HTTPAuth::DigestAuth in Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 has a regular expression Denial of Service cause by looping/backtracking. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 mishandles path checking within File.fnmatch functions. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
An issue was discovered in Ruby before 2.3.8, 2.4.x before 2.4.5, 2.5.x before 2.5.2, and 2.6.x before 2.6.0-preview3. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
An issue was discovered in the OpenSSL library in Ruby before 2.3.8, 2.4.x before 2.4.5, 2.5.x before 2.5.2, and 2.6.x before 2.6.0-preview3. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, the Dir.open, Dir.new, Dir.entries and Dir.empty? methods do not check NULL characters. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, the UNIXServer.open and UNIXSocket.open methods are not checked for null characters. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, an attacker controlling the unpacking format (similar to format string vulnerabilities) can. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, an attacker can pass a large HTTP request with a crafted header to WEBrick server or a crafted. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Directory traversal vulnerability in the Dir.mktmpdir method in the tmpdir library in Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1 might allow. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
The lazy_initialize function in lib/resolv.rb in Ruby through 2.4.3 uses Kernel#open, which might allow Command Injection attacks, as demonstrated by a Resolv::Hosts::new argument beginning with a. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Ruby before 2.4.3 allows Net::FTP command injection. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and EPSS exploitation probability 88.6%.