Apache Airflow versions 3.0.0 through 3.1.8 DagRun wait endpoint returns XCom result values even to users who only have DAG Run read permissions, such as the Viewer role.This behavior conflicts with the FAB RBAC model, which treats XCom as a separate protected resource, and with the security model documentation that defines the Viewer role as read-only. Airflow uses the FAB Auth Manager to manage access control on a per-resource basis. The Viewer role is intended to be read-only by default, and the security model documentation defines Viewer users as those who can inspect DAGs without accessing sensitive execution results. Users are recommended to upgrade to Apache Airflow 3.2.0 which resolves this issue.

osslsigncode is a tool that implements Authenticode signing and timestamping. Prior to 2.13, an out-of-bounds read vulnerability exists in osslsigncode version 2.12 and earlier in the PE page-hash computation code (pe_page_hash_calc()). When processing PE sections for page hashing, the function uses PointerToRawData and SizeOfRawData values from section headers without validating that the referenced region lies within the mapped file. An attacker can craft a PE file with section headers that point beyond the end of the file. When osslsigncode computes page hashes for such a file, it may attempt to hash data from an invalid memory region, causing an out-of-bounds read and potentially crashing the process. The vulnerability can be triggered while signing a malicious PE file with page hashing enabled (-ph), or while verifying a malicious signed PE file that already contains page hashes. Verification of an already signed file does not require the verifier to pass -ph. This vulnerability is fixed in 2.13.

Dual-Algorithm CertificateVerify out-of-bounds read. When processing a dual-algorithm CertificateVerify message, an out-of-bounds read can occur on crafted input. This can only occur when --enable-experimental and --enable-dual-alg-certs is used when building wolfSSL.

V2Board 1.6.1 through 1.7.4 and Xboard through 0.1.9 expose authentication tokens in HTTP response bodies of the loginWithMailLink endpoint when the login_with_mail_link_enable feature is active. Unauthenticated attackers can POST to the loginWithMailLink endpoint with a known email address to receive the full authentication URL in the response, then exchange the token at the token2Login endpoint to obtain a valid bearer token with complete account access including admin privileges.

Heap buffer overflow in CertFromX509 via AuthorityKeyIdentifier size confusion. A heap buffer overflow occurs when converting an X.509 certificate internally due to incorrect size handling of the AuthorityKeyIdentifier extension.

ChurchCRM is an open-source church management system. Prior to 7.1.0, an XSS vulnerability allows attacker-supplied input sent via a the EName and EDesc parameters in EditEventAttendees.php to be rendered in a page without proper output encoding, enabling arbitrary JavaScript execution in victims' browsers. This vulnerability is fixed in 7.1.0.

OpenClaw before 2026.3.25 contains a pre-authentication rate-limit bypass vulnerability in webhook token validation that allows attackers to brute-force weak webhook secrets. The vulnerability exists because invalid webhook tokens are rejected without throttling repeated authentication attempts, enabling attackers to guess weak tokens through rapid successive requests.

SiYuan is a personal knowledge management system. Prior to 3.6.4, SiYuan configures Mermaid.js with securityLevel: "loose" and htmlLabels: true. In this mode, <img> tags with src attributes survive Mermaid's internal DOMPurify and land in SVG <foreignObject> blocks. The SVG is injected via innerHTML with no secondary sanitization. When a victim opens a note containing a malicious Mermaid diagram, the Electron client fetches the URL. On Windows, a protocol-relative URL (//attacker.com/image.png) resolves as a UNC path (\\attacker.com\image.png). Windows attempts SMB authentication automatically, sending the victim's NTLMv2 hash to the attacker. This vulnerability is fixed in 3.6.4.

In TLSX_EchChangeSNI, the ctx->extensions branch set extensions unconditionally even when TLSX_Find returned NULL. This caused TLSX_UseSNI to attach the attacker-controlled publicName to the shared WOLFSSL_CTX when no inner SNI was configured. TLSX_EchRestoreSNI then failed to clean it up because its removal was gated on serverNameX != NULL. The inner ClientHello was sized before the pollution but written after it, causing TLSX_SNI_Write to memcpy 255 bytes past the allocation boundary.

A stack buffer overflow exists in wolfSSL's PKCS7 implementation in the wc_PKCS7_DecryptOri() function in wolfcrypt/src/pkcs7.c. When processing a CMS EnvelopedData message containing an OtherRecipientInfo (ORI) recipient, the function copies an ASN.1-parsed OID into a fixed 32-byte stack buffer (oriOID[MAX_OID_SZ]) via XMEMCPY without first validating that the parsed OID length does not exceed MAX_OID_SZ. A crafted CMS EnvelopedData message with an ORI recipient containing an OID longer than 32 bytes triggers a stack buffer overflow. Exploitation requires the library to be built with --enable-pkcs7 (disabled by default) and the application to have registered an ORI decrypt callback via wc_PKCS7_SetOriDecryptCb().