rainbutterfly/cve_corpus huggingface dataset:
CVE-2026-42785 OpenKM 6.3.12 Remote Code Execution via Administrative Scripting
OpenKM 6.3.12 contains a remote code execution vulnerability that allows authenticated administrators to execute arbitrary Java/BeanShell code through the /admin/Scripting endpoint. Attackers can submit malicious script content with an action=Evaluate parameter to execute operating system commands in the context of the OpenKM application server.
Problem types: cwe_id: CWE-94
description: Improper Control of Generation of Code ('Code Injection')
Affected products: vendor: Openkm
product: OpenKM Community Edition
default_status: unknown
vendor: Openkm
product: OpenKM Professional Edition
default_status: unknown
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 7.2
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: HIGH
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Credits: lang: en
value: Terra System Labs Pvt. Ltd.
Published: 2026-05-26T14:08:51.032Z
CVE-2026-42786 WebSocket fragmented message reassembly unbounded in bandit
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated remote denial of service via memory exhaustion.

The fragment reassembly path in 'Elixir.Bandit.WebSocket.Connection':handle_frame/3 in lib/bandit/websocket/connection.ex appends every incoming Continuation{fin: false} frame's payload to a per-connection iolist with no cumulative size cap. The existing max_frame_size option only bounds individual frames; a peer that streams an unbounded number of continuation frames without ever setting fin=1 grows BEAM heap linearly until the OS or a supervisor kills the process.

Because the accumulation happens before WebSock.handle_in/2 is called, the application has no opportunity to interpose a size check. Phoenix Channels and LiveView both run over WebSock on Bandit, so a stock Phoenix application exposes this surface as soon as it accepts socket connections.

This issue affects bandit: from 0.5.0 before 1.11.0.
Problem types: cwe_id: CWE-770
description: CWE-770 Allocation of Resources Without Limits or Throttling
Affected products: vendor: mtrudel
product: bandit
cpes: cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: mtrudel
product: bandit
cpes: cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
default_status: unaffected
Credits: lang: en
value: Peter Ullrich
lang: en
value: Mat Trudel
lang: en
value: Jonatan Männchen / EEF
Published: 2026-05-01T20:34:17.014Z
CVE-2026-42788 HTTP/2 frame size limit checked after body is buffered in bandit
Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.

'Elixir.Bandit.HTTP2.Frame':deserialize/2 in lib/bandit/http2/frame.ex checks the SETTINGS_MAX_FRAME_SIZE limit only after pattern-matching payload::binary-size(length), which requires the entire frame body to be present in memory before either the accept or reject clause can fire. A peer that announces a frame length up to the 24-bit maximum (~16 MiB) causes the server to buffer that entire body before the size guard is evaluated, regardless of the max_frame_size negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113).

An unauthenticated attacker holding many concurrent connections can force the server to buffer far more memory than the negotiated frame size limit should permit, leading to memory pressure and potential denial of service.

This issue affects bandit: from 0.3.6 before 1.11.0.
Problem types: cwe_id: CWE-770
description: CWE-770 Allocation of Resources Without Limits or Throttling
Affected products: vendor: mtrudel
product: bandit
cpes: cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: mtrudel
product: bandit
cpes: cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
default_status: unaffected
Credits: lang: en
value: Peter Ullrich
lang: en
value: Mat Trudel
lang: en
value: Jonatan Männchen / EEF
Published: 2026-05-01T20:34:11.911Z
CVE-2026-42789 Non-CA certificate accepted as intermediate issuer in public_key path validation
Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.

In lib/public_key/src/pubkey_cert.erl, pubkey_cert:validate_extensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to public_key:pkix_path_validation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.

Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim's trust store, can use that certificate's private key to sign forged leaf certificates for arbitrary identities. public_key:pkix_path_validation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.

This issue affects OTP from OTP 17.0 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
Problem types: cwe_id: CWE-295
description: CWE-295 Improper Certificate Validation
cwe_id: CWE-296
description: CWE-296 Improper Following of a Certificate's Chain of Trust
Affected products: vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
Credits: lang: en
value: John Downey
lang: en
value: Ingela Anderton Andin
lang: en
value: Jakub Witczak
Published: 2026-05-27T12:23:06.355Z
CVE-2026-42790 nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification
Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.

Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):

First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.

Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback.

The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hostname matcher.

This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
Problem types: cwe_id: CWE-295
description: CWE-295 Improper Certificate Validation
cwe_id: CWE-297
description: CWE-297 Improper Validation of Certificate with Host Mismatch
Affected products: vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
Credits: lang: en
value: John Downey
lang: en
value: Ingela Anderton Andin
lang: en
value: Dan Gudmundsson
lang: en
value: Jakub Witczak
Published: 2026-05-27T15:09:01.860Z
CVE-2026-42791 OCSP responder certificate validity period not checked in public_key
Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows forged OCSP responses signed with an expired responder certificate to be accepted as valid.

OCSP response verification in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid.

This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling public_key:pkix_ocsp_validate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate.

This issue affects OTP from OTP 27.0 before OTP 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.16 before 1.17.1.3, 1.20.3.1, and 1.21.1.
Problem types: cwe_id: CWE-295
description: CWE-295 Improper Certificate Validation
cwe_id: CWE-672
description: CWE-672 Operation on a Resource after Expiration or Release
Affected products: vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
vendor: Erlang
product: OTP
cpes: cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*
default_status: unknown
Credits: lang: en
value: Jakub Witczak
lang: en
value: Ingela Anderton Andin
Published: 2026-05-27T12:23:13.584Z
CVE-2026-42793 Atom table exhaustion via attacker-controlled GraphQL SDL names in absinthe
Allocation of Resources Without Limits or Throttling vulnerability in absinthe-graphql absinthe allows unauthenticated denial of service via atom table exhaustion when parsing attacker-controlled GraphQL SDL.

Multiple Blueprint.Draft.convert/2 implementations in Absinthe's SDL language modules call String.to_atom/1 on attacker-controlled names from parsed GraphQL SDL documents, including directive names, field names, type names, and argument names. Because atoms are never garbage-collected and the BEAM atom table has a fixed limit (default 1,048,576), each unique name permanently consumes one slot. An attacker can exhaust the atom table by submitting SDL documents containing enough unique names, causing the Erlang VM to abort with system_limit and taking down the entire node.

Any application that passes attacker-controlled GraphQL SDL through Absinthe's parser is exposed — for example, a schema-upload endpoint, a federation gateway that ingests remote SDL, or any developer tool that runs the parser over user-supplied documents.

This issue affects absinthe: from 1.5.0 before 1.10.2.
Problem types: cwe_id: CWE-770
description: CWE-770 Allocation of Resources Without Limits or Throttling
Affected products: vendor: absinthe-graphql
product: absinthe
cpes: cpe:2.3:a:absinthe-graphql:absinthe:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: absinthe-graphql
product: absinthe
cpes: cpe:2.3:a:absinthe-graphql:absinthe:*:*:*:*:*:*:*:*
default_status: unaffected
Credits: lang: en
value: Peter Ullrich
lang: en
value: Curtis Schiewek
Published: 2026-05-08T15:42:46.101Z
CVE-2026-42794 Reflected XSS via backslash bypass in GraphiQL js_escape in absinthe_plug
Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in absinthe-graphql absinthe_plug allows reflected cross-site scripting via the GraphiQL interface.

'Elixir.Absinthe.Plug.GraphiQL':js_escape/1 in lib/absinthe/plug/graphiql.ex escapes single quotes and newlines in the query GET parameter before embedding it in an inline JavaScript string, but does not escape backslashes. An attacker can bypass the escaping by prefixing a quote with a backslash (e.g. \'), breaking out of the string context and executing arbitrary JavaScript in the victim's browser.

This issue affects absinthe_plug: from 1.2.0 before 1.5.10.
Problem types: cwe_id: CWE-79
description: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: absinthe-graphql
product: absinthe_plug
cpes: cpe:2.3:a:absinthe-graphql:absinthe_plug:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: absinthe-graphql
product: absinthe_plug
cpes: cpe:2.3:a:absinthe-graphql:absinthe_plug:*:*:*:*:*:*:*:*
default_status: unaffected
Credits: lang: en
value: 40826d
lang: en
value: Bryan A. Enders
lang: en
value: Leandro Moreno
lang: en
value: Ben Wilson
Published: 2026-05-08T15:42:40.706Z
CVE-2026-42795 Symlink Following in Hex Package Export Allows Embedding Files Outside Project Root
Symlink following vulnerability in Gleam's Hex package export allows files outside the project root to be embedded in the generated package tarball.

The file collection helpers (gleam_files, native_files, private_files) in compiler-cli/src/fs.rs use follow_links(true) when walking publishable directories such as src/ and priv/. The collected paths are added to the package archive via add_path_to_tar in compiler-cli/src/publish.rs without verifying that the resolved target remains within the project root. A symlink placed under a publishable directory will cause gleam export hex-tarball or gleam publish to embed the contents of the symlink target into the generated Hex package.

An attacker with write access to the project repository can place a symlink in src/ or priv/ pointing to an arbitrary file. When a maintainer or CI pipeline runs gleam publish or gleam export hex-tarball, local files readable by the publisher (such as secrets, tokens, or SSH keys) are silently embedded into the published package artifact.

This issue affects Gleam from 0.10.0-rc1 until 1.17.0.
Problem types: cwe_id: CWE-59
description: CWE-59 Improper Link Resolution Before File Access ('Link Following')
Affected products: vendor: Gleam
product: Gleam
cpes: cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: Gleam
product: Gleam
cpes: cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*
default_status: unaffected
vendor: Gleam
product: Gleam
cpes: cpe:2.3:a:gleam-lang:gleam:*:*:*:*:*:*:*:*
default_status: unaffected
Credits: lang: en
value: Aly (spect3r1)
lang: en
value: Abdelrahman Ahmed Aboelkasem (0x2face)
lang: en
value: Louis Pilfold
lang: en
value: Jonatan Männchen / EEF
Published: 2026-06-02T13:41:39.527Z
CVE-2026-42796 Arelle < 2.39.10 Unauthenticated RCE via /rest/configure
Arelle before 2.39.10 contains an unauthenticated remote code execution vulnerability in the /rest/configure REST endpoint that accepts a plugins query parameter and forwards it to the plugin manager without authentication or authorization. Attackers can supply a URL to a malicious Python file through the plugins parameter, causing the Arelle webserver to download and execute the attacker-controlled code within the Arelle process with its privileges.
Problem types: cwe_id: CWE-306
description: CWE-306 Missing Authentication for Critical Function
Affected products: vendor: Arelle
product: Arelle
default_status: affected
CVSS v3.1: attackVector: NETWORK
attackComplexity: LOW
privilegesRequired: NONE
userInteraction: NONE
scope: UNCHANGED
confidentialityImpact: HIGH
integrityImpact: HIGH
availabilityImpact: HIGH
version: 3.1
baseSeverity: CRITICAL
baseScore: 9.8
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Credits: lang: en
value: Mobasi Security Team
Published: 2026-05-04T17:19:43.020Z
CVE-2026-42797 Apache Syncope: JexlContextBuilder Information Disclosure
Exposure of Sensitive Information Through Data Queries vulnerability in Apache Syncope.

An administrator with adequate entitlements for Derived Schemas can create a malicious JEXL expression which allows any administrator with sufficient entitlements for User read to access User-related security-sensitive information.

This issue affects Apache Syncope: 3.0 through 3.0.16, 4.0 through 4.0.5, 4.1.0.

Users are recommended to upgrade to version 4.0.6 / 4.1.1, which fix this issue by further restricting the JEXL expression definition.
Problem types: cwe_id: CWE-202
description: CWE-202 Exposure of Sensitive Information Through Data Queries
Affected products: vendor: Apache Software Foundation
product: Apache Syncope
default_status: unaffected
Credits: lang: en
value: elin kai
Published: 2026-05-25T15:00:55.670Z
CVE-2026-42798 
Little CMS (lcms2) 2.16 through 2.18 before 2.19 has an integer overflow in ParseCube in cmscgats.c.
Problem types: cwe_id: CWE-190
description: CWE-190 Integer Overflow or Wraparound
Affected products: vendor: littlecms
product: little cms color engine
default_status: unaffected
CVSS v3.1: attackComplexity: HIGH
attackVector: LOCAL
availabilityImpact: LOW
baseScore: 4
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L
version: 3.1
Published: 2026-04-30T06:34:13.323Z
CVE-2026-42799 Out-of-bounds read in ulp
Out-of-bounds read vulnerability in ASR Kestrel (nr_fw modules) allows Overflow Buffers.

 This vulnerability is associated with program files Code/Nr/nr_fw/RA/src/NrPwrCtrl.C.



This issue affects Kestrel: before 2026/02/10.
Problem types: cwe_id: CWE-125
description: CWE-125 Out-of-bounds read
Affected products: vendor: ASR
product: Kestrel
default_status: unaffected
CVSS v3.1: version: 3.1
attackVector: NETWORK
attackComplexity: LOW
privilegesRequired: LOW
userInteraction: NONE
scope: CHANGED
confidentialityImpact: LOW
integrityImpact: LOW
availabilityImpact: LOW
baseSeverity: HIGH
baseScore: 7.4
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
Published: 2026-04-30T08:36:22.958Z
CVE-2026-42800 Deference after null check in ims_client sip
NULL pointer dereference vulnerability in ASR1903 in ASR Lapwing_Linux on Linux (ims_client modules) allows Pointer Manipulation.

 This vulnerability is associated with program files sip/utils/src/sipuri.c.
Problem types: cwe_id: CWE-476
description: CWE-476 NULL pointer dereference
Affected products: vendor: ASR
product: Lapwing_Linux
default_status: unaffected
CVSS v3.1: version: 3.1
attackVector: NETWORK
attackComplexity: LOW
privilegesRequired: LOW
userInteraction: NONE
scope: CHANGED
confidentialityImpact: LOW
integrityImpact: LOW
availabilityImpact: LOW
baseSeverity: HIGH
baseScore: 7.4
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
Published: 2026-04-30T08:52:01.816Z
CVE-2026-42809 Apache Polaris: staged table creation could vend storage credentials for unvalidated locations
Apache Polaris can issue broad temporary ("vended") storage credentials during
staged
table creation before the effective table location has been validated or
durably reserved. 
Those temporary credentials are meant to limit the scope
of
accessible table data and metadata, but this scope limitation becomes
attacker-
directed because the attacker can choose a reachable target location.



In the confirmed variant, if the caller supplies a custom `location` during
stage create and requests credential vending, Apache Polaris uses that location to
construct delegated storage credentials immediately. The stage-create path
itself neither runs the normal location validation nor the overlap checks
before those credentials are issued.



Closely related to that, the staged-create flow also accepts
`write.data.path` / `write.metadata.path` in the request properties and
feeds
those location overrides into the same effective table location set used for
credential vending. Those fields are secondary to the main custom-`location`
exploit, but they are still attacker-influenced location inputs that should
be
validated before any credentials are issued.
Problem types: cwe_id: CWE-862
description: CWE-862 Missing Authorization
cwe_id: CWE-20
description: CWE-20 Improper Input Validation
Affected products: vendor: Apache Software Foundation
product: Apache Polaris
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 9.9
baseSeverity: CRITICAL
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: CHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
version: 3.1
Published: 2026-05-04T16:22:48.527Z
CVE-2026-42810 Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names
Apache Polaris accepts literal `*` characters in namespace and table names. When it
later builds temporary S3 access policies for delegated table access, those
same characters appear to be reused unescaped in S3 IAM resource patterns
and
`s3:prefix` conditions.



In S3 IAM policy matching, `*` is treated as a wildcard rather than as
ordinary text. That means temporary credentials issued for one crafted table
can match the storage path of a different table.



In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-
credential path on both MinIO and real AWS S3, credentials returned for
crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other
tables' S3 locations.


The confirmed behavior includes:


- reading another table's metadata control file ([Iceberg metadata JSON]);

- listing another table's exact S3 table prefix ([table prefix]);

- and, when write delegation was returned for the crafted table, creating
and
deleting an object under another table's exact S3 table prefix.



A control case using ordinary different names did not allow the same
cross-table access.



A least-privilege AWS S3 variant was also confirmed in which the attacker
principal had no Polaris permissions on the victim table and only the
minimal permissions required to create and use a crafted wildcard table
(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that
setup, direct Polaris access to `foo.t1` remained forbidden, but the
attacker
could still create and load `*.*`, receive delegated S3 credentials, and use
those credentials to list, read, create, and delete objects under `foo.t1`.



In Iceberg, the metadata JSON file is a control file: it tells readers which
data files belong to the table, which snapshots exist, and which table
version
to read. So unauthorized access to it is already a meaningful
confidentiality
problem. The confirmed write-capable variant means the issue is not limited
to
disclosure.
Problem types: cwe_id: CWE-116
description: CWE-116 Improper Encoding or Escaping of Output
cwe_id: CWE-20
description: CWE-20 Improper Input Validation
Affected products: vendor: Apache Software Foundation
product: Apache Polaris
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 9.9
baseSeverity: CRITICAL
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: CHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
version: 3.1
Published: 2026-05-04T16:48:49.754Z