Cross-origin data disclosure in Google Chrome versions prior to 153.0.8010.47 occurs when an attacker who has already compromised the renderer process lures a victim to a crafted HTML page. The weakness lives in the GetUserMedia media-capture code path, where incomplete cleanup (CWE-459) leaves cross-origin data recoverable, as captured by the CVSS v3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N (score 3.1) - unauthenticated network reach but high attack complexity, mandatory user interaction, and confidentiality-only, low-magnitude impact. No public exploit code or confirmed active exploitation has been identified at time of analysis, and Google has shipped the fix in Chrome 153.0.8010.47.
Partial denial of service in Oracle Access Manager 12.2.1.4.0 and 14.1.2.1.0 (Access SDK component) can be triggered by a low-privileged, authenticated attacker who reaches the product over HTTP. The flaw is rated CVSS 3.1 base 3.1 with an availability-only, partial impact, and Oracle characterizes it as difficult to exploit (AC:H), so successful disruption requires favorable timing or state rather than a simple repeatable request. No public exploit code, EPSS score, or CISA KEV entry was present in the supplied intelligence, so there is no indication of active exploitation at time of analysis.
Use-after-free in Chrome's Skia graphics library allows an attacker who has already compromised the renderer process to read cross-origin data after a victim opens a crafted HTML page in Chrome versions prior to 153.0.8010.47. Chromium rates the bug High severity because it can breach the same-origin boundary, even though the CVSS base score is only 3.1 (confidentiality-limited, no integrity or availability impact). No public exploit code or CISA KEV entry is associated with this CVE at time of analysis, and the attack is not automatable per CISA's SSVC assessment.
Cross-origin data disclosure in Google Chrome prior to 153.0.8010.47: a race condition (TOCTOU) in the browser's Network component lets a remote attacker who has already achieved code execution inside the renderer process read data belonging to other origins by luring a victim to a crafted HTML page. The impact is limited to confidentiality of cross-origin responses (C:L, I:N, A:N), and exploitation is rated High complexity with required user interaction; no public exploit code or CISA KEV entry was present in the supplied intelligence, and the vendor has shipped a fix in 153.0.8010.47.
PHPGurukul Blood Donor Management System 1.0 stores credentials in cleartext on disk when crafted values are supplied to the password, email, currentpassword, dbcurrentpwd, or newpassword arguments handled by application/models/admin/Login_Model.php. Vulnerable code paths are reachable remotely per the CVSS 4.0 vector (AV:N/PR:N/UI:N), although exploitation complexity is rated high (AC:H) and only a low confidentiality impact is scored. Publicly available exploit code exists and is flagged with an Exploit maturity of P in the CVSS vector, so the flaw should be treated as exploitable even though the base score is only 2.9 and no CISA KEV entry is present.
Oracle Coherence 15.1.1.0.0 exposes a narrow local information-disclosure weakness in its Core component that lets an attacker who already holds a low-privileged operating-system logon on the Coherence host read a limited subset of data the process can access. The flaw is rated CVSS 3.1 base 2.5 (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), meaning high attack complexity, no integrity or availability impact, and no remote vector. There is no public exploit code and no CISA KEV listing, so this is a low-priority, defense-in-depth item rather than an emergency; Oracle published it through its Critical Patch Update advisory for Fusion Middleware.
Heap out-of-bounds access in GPAC's URL concatenation utility (`utils/url.c`) allows a local low-privileged attacker to trigger memory corruption when the `gf_url_concatenate_ex` function processes a crafted URL that results in an empty temporary buffer. The trailing-whitespace trim loop computes `tmp[strlen(tmp)-1]` without first checking that `tmp` is non-empty, accessing heap memory at index -1. Exploitation requires local system access and user interaction; no public exploit exists and the vulnerability is not listed in CISA KEV. The fix is available in GPAC release abi-16.23.
Stored cross-site scripting in Concrete CMS 5.0.0 through 9.5.2 lets an unauthenticated attacker inject raw HTML through a publicly accessible Express Form; the payload is rendered unsanitized as an Express entry label whenever associated entries are displayed, executing in an administrator's dashboard session and in the browsers of visitors to pages containing an Express Entry List block with association columns. The Concrete CMS security team rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:N/UI:P), reflecting that exploitation depends on specific Express configuration and passive victim interaction rather than open, unconditional exposure. No public exploit code or CISA KEV listing was identified at time of analysis, and fixed code is available in Concrete CMS 9.5.3.
Use-after-free in FreeRDP's smartcard RDPDR device handler (before 3.31.0) allows a malicious or compromised RDP server to free a registered device pointer while the device manager still holds a reference, producing a dangling pointer that can crash the client or potentially be leveraged for code execution in the victim's session. The flaw is only reachable when a client with smartcard redirection enabled connects to an attacker-controlled RDP endpoint and the attacker can force a worker-thread creation failure during channel setup — a narrow, non-deterministic window reflected in the low CVSS 4.0 score of 2.3 (AV:N/AC:H/AT:P/PR:N/UI:P, availability-only impact). A vendor patch is available in FreeRDP 3.31.0; no public exploit code and no CISA KEV listing were identified at time of analysis.
Concrete CMS versions below 9.5.3 import files uploaded through the conversation attachment endpoint into the site's file manager before verifying the 'Add Message Attachments' permission, so the authorization check happens only after the file has already been stored. A low-privileged authenticated user who has been explicitly denied that permission — or an unauthenticated visitor on a site configured to allow guest posting — can therefore inject files of allowed types into the file manager, altering stored content or consuming storage. The vendor rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L), indicating limited integrity and availability impact rather than code execution, and there is no public exploit code identified at time of analysis.
Concrete CMS 8.5.3 through 9.5.2 lets a suspended or deactivated user keep minting valid OAuth 2.0 access tokens through the refresh-token grant, because the grant never re-checks the account's active flag (uIsActive=0) before issuing new tokens. Anyone who legitimately obtained a refresh token while their account was active retains API access after offboarding, so deactivation alone no longer revokes API credentials. The vendor assigned a low CVSS v4.0 base score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N, all impacts Low); no public exploit code or CISA KEV listing was provided at time of analysis.
Cross-site request forgery in the Concrete CMS dashboard 'SEO Excluded Words' reset action lets a remote attacker who lures an authenticated administrator to a crafted page silently wipe the site's reserved-word list (concrete.seo.exclude_words) and restore vendor defaults, in every release below 9.5.3. The reset() controller validated neither the anti-CSRF token emitted by its own modal nor the HTTP method, so a cross-site request from the victim's authenticated browser is honoured. The impact is integrity-only and narrowly scoped — future automatically generated URL slugs for pages, files and topics stop honouring the site's SEO policy — and the vendor rates it CVSS 4.0 2.3; no public exploit code or CISA KEV entry was identified at the time of analysis.
Concrete CMS versions 9.0.0 through 9.5.2 fail to validate a CSRF token on the dashboard group type controller's delete action, allowing a remote attacker to force a logged-in administrator into deleting a custom group type. The attacker needs no authentication of their own but must lure a victim who holds group type management permission into visiting a malicious page while logged in, which is why the vendor rated it only 2.3 under CVSS 4.0. There is no indication of active exploitation or public exploit code, and the issue is fixed in the 9.5.3 release.
Concrete CMS versions below 9.5.3 fail to validate an anti-CSRF token on the block-arrangement backend endpoint (Concrete\Controller\Backend\Page\ArrangeBlocks::arrange), so a session-holding content editor can be tricked into silently reordering or moving blocks in the draft of a page they are allowed to edit. Exploitation is browser-driven cross-site request forgery: the attacker needs only to lure a logged-in editor to an attacker-controlled page while the default null SameSite cookie setting lets the victim's session cookie ride along with the forged request. Impact is limited to integrity of draft content layout (CVSS v4.0 2.3, CWE-352); no public exploit code and no active exploitation are indicated in the supplied intelligence, and no EPSS score was provided.
Local file enumeration in Keyfactor SignServer before 7.6.0 allows an authenticated administrator to confirm the existence and readability of arbitrary files on the application server by pointing configurable path properties at them and observing distinguishable error responses. The three affected properties are ATTRIBUTESFILE in PKCS11CryptoToken, KEYSTOREPATH in KeyStoreCryptoToken, and TRUSTSTOREPATH in RenewalWorker. No file contents are disclosed, exploitation requires a high-privileged admin account (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, base 2.3), and there is no public exploit identified at time of analysis; EPSS is 0.15% (5th percentile), consistent with a low-priority information-disclosure issue.
Concrete CMS 9.5.2 and earlier fail to enforce a destination-side authorization check and omit CSRF token validation in the multilingual page-assignment backend action (Backend\Page\Multilingual::assign), letting an authenticated editor who holds the Edit Page Multilingual Settings permission on just one page rebind an arbitrary page from another locale as that page's translation and delete legitimate translation pairs maintained by other editors. The result is silent manipulation of public-facing language routing across the site, with no confidentiality impact and only limited integrity/availability damage. The vendor scores this 2.1 (CVSS v4.0) because the actor must already be an authenticated, privileged editor; no public exploit code and no active exploitation have been reported.
Reflected cross-site scripting in Concrete CMS versions 5.0.0 through 9.5.2 lets an attacker run arbitrary JavaScript in a victim's browser by abusing the conversation messages feature's handling of a user-supplied custom date format. Because the conversation view endpoint carries no CSRF token, the payload can be delivered through an auto-submitting cross-origin POST from an attacker-controlled page, and the independently assessed vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) treats the attack as unauthenticated, requiring only that the victim load a malicious page. Impact is limited to the victim's browser session - reflected rather than stored XSS, with partial confidentiality and integrity loss and no availability impact - and the vendor's own CVSS v4.0 score of 2.1 (AT:P/PR:L/UI:P) reflects that exploitability depends on attacker-provided content and victim interaction; no public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fully remediated in 9.5.3.
Server-side request forgery in Concrete CMS 9.0.0 through 9.5.2 allows an authenticated user who holds file-import privileges to make the server fetch internal-only resources by abusing a DNS pin that is validated once per host and then reused for every later URL on that host. Because the pinned validation and the unpinned download can resolve to different addresses, a rebinding host can redirect the request to loopback services, internal admin panels, or cloud metadata endpoints, with responses saved into the file manager. The vendor rates this only CVSS 4.0 base 2.1 given the high complexity and privileged prerequisite; no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS 9.0.0 through 9.5.2 contains an insecure direct object reference in the Express saved search preset delete and edit dialogs, letting any authenticated user who holds only view permission on a single Express entity permanently delete (with no undo) or rename saved search presets owned by Express entities they have no permission over. Because a renamed preset is rendered back to users of the targeted entity, the flaw enables content defacement or social-engineering-style manipulation of other teams' saved searches. The vendor scored it CVSS 4.0 2.1 (Low) with PR:H and AT:P; no public exploit code, EPSS score, or CISA KEV listing was identified at time of analysis.
Broken authorization in the Concrete CMS 9 Boards dashboard area (versions 9 through 9.5.2) lets any user who has been granted edit_board_settings on a single board view, refresh, regenerate, or delete board instances belonging to entirely different boards by supplying those boards' instance IDs. The affected single-page controllers resolve an instance directly from the attacker-supplied ID and validate only an action-scoped CSRF token — which is bound to the action name, not to the target object, and is therefore reusable across boards — while skipping the permission-checked accessor that runs canEditBoardSettings on the parent board for the read view. The vendor rates this CVSS v4.0 2.1 (AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L); no public exploit code or CISA KEV listing was identified at time of analysis.
Authenticated users with editor-level or higher privileges in Concrete CMS 9.x before 9.5.3 can degrade site availability by submitting keyword searches packed with SQL LIKE wildcard characters, which the application failed to escape before placing them into the LIKE clause. Because a single-character wildcard matches any row, a short request forces the database into full-table scans, and repeated or wildcard-dense searches can sustain elevated database CPU and I/O on large installations, slowing the site for all users. The Concrete CMS security team rated this CVSS v4.0 2.1 (availability-only, attack requirements present, high privileges); no public exploit code has been identified at time of analysis.
Missing authorization in the Express entries advanced-search dashboard action of Concrete CMS 9.0.0 through 9.5.2 lets any authenticated dashboard user who holds view_express_entries on just one Express entity read the entries and secret attribute values of every other Express entity. The advanced_search() method resolves the target entity directly from a user-supplied entity ID and skips the canViewExpressEntries() check that the sibling results() action enforces, crossing the per-entity permission boundary Express is designed to guarantee. The vendor rates this CVSS v4.0 2.1 (AV:N/AC:L/AT:P/PR:H/UI:N/VC:L), reflecting a low-impact but real confidentiality breach limited to authenticated staff; no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS 9 through 9.5.2 fails to verify ownership when processing three Boards data-source dashboard actions (update, update_data_source, delete_data_source), so an authenticated user with edit_board_settings on just one board can modify or permanently delete the configured data sources of any other board on the site. Successful abuse halts the victim board's content feed and resets its custom weighting, with no confidentiality impact. The vendor-assigned CVSS v4.0 base score is a low 2.1 (PR:H, AT:P), no public exploit code or CISA KEV entry was provided in the intelligence feed, and the referenced fix is the Concrete CMS 9.5.3 release notes.
Concrete CMS versions before 9.5.3 contain a missing-authorization flaw in the SEO Bulk Update Meta Tags editor: the saveRecord() action validated the per-page CSRF token but never invoked canEditPageProperties() for the target page. As a result, an authenticated user who was granted access to the bulk SEO tool and could merely view a page could rewrite that page's meta title, meta description, and URL handle, tampering with presentation content and live URLs outside their intended edit scope. The vendor rates this only 2.1 (CVSS v4.0, integrity-only), there is no public exploit code identified at time of analysis, and the issue is not known to be actively exploited (no CISA KEV listing).
Missing per-page authorization in the Concrete CMS sitemap controller (all versions before 9.5.3) lets any authenticated dashboard user who can reach the sitemap reorder pages they have no edit or arrange rights over, silently altering the site's global navigation order. The send_to_top and send_to_bottom tasks trust the attacker-supplied cNodeID parameter and load/update the target page without verifying move permission on that specific node (CWE-862); impact is integrity-only (CVSS v4.0 2.1, PR:H, VI:L). No public exploit code or CISA KEV entry was identified at time of analysis, and a vendor fix is available in Concrete CMS 9.5.3.
Cross-site request forgery in Concrete CMS before 9.5.3 lets a remote attacker silently create theme page-template records inside a logged-in administrator's session. The Dashboard theme Inspect controller's activate_files() action accepts attacker-supplied pageTemplates[] values without validating an anti-CSRF token, so a forged auto-submitting POST from a page the admin merely visits is honored as legitimate. Impact is limited to unauthorized configuration change (integrity only, CVSS v4.0 base 2.1), and no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS 9.0.0 through 9.5.2 lets an authenticated user who holds only the global access_sitemap permission reorder any page in the site tree, including pages they have no rights to edit, because the dashboard sitemap reorder controller (Concrete\Controller\Backend\Dashboard\SitemapUpdate) never checks per-page edit permission before writing each page's cDisplayOrder value. The same action validates no CSRF token, so a forged request from a sitemap-privileged victim's browser can perform the write silently, changing the order in which pages appear in navigation menus, breadcrumbs, and page lists. Concrete CMS shipped a fix in 9.5.3; the vendor rates the issue CVSS v4.0 2.1 (integrity-only, no confidentiality or availability impact), and there is no public exploit code or CISA KEV listing identified at time of analysis.
Concrete CMS versions 9.4.0 through 9.5.2 fail to escape page paths before rendering them inside the location panel's duplicate-path confirmation dialog: the panel's check endpoint reflects the submitted path unmodified in its JSON response, and client-side JavaScript injects that value as raw HTML, so a crafted path executes script in an authenticated editor's browser session. An attacker must already hold page-authoring privileges and must engineer a path collision so the confirmation dialog appears, and the victim must then open that panel; no public exploit code or CISA KEV entry is associated with this CVE at time of analysis.
Let me synthesize. CVE-2026-18426: Concrete CMS 9.0.0 through 9.5.2, missing block-level edit permission check on Express Form block control-management actions, relying solely on CSRF token validation. Token bound to user and action, not block/page/form. So authenticated user with edit access to one Express Form could reuse token to add/modify/delete controls on forms they aren't authorized to edit, including injecting control whose value later rendered as HTML → stored XSS. CVSS 4.0 2.0, AV:N/AC:H/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N. CWE-862 missing authorization. Tags: XSS, Authentication Bypass, CSRF. Hmm — "Authentication Bypass" tag is arguably mislabeled since it's a missing authorization check (CWE-862), not authentication bypass. Actually that's a good candidate for data_quality_flags mislabeled_tag. The tag "Authentication Bypass" is wrong — this is an authorization flaw (CWE-862), not authentication bypass. Confidence: medium/high. I'd say medium-high. Let's use "high" given CWE-862 is explicitly missing authorization and PR:H required (authenticated user). Actually the tag list includes both XSS and CSRF — both apply somewhat (stored XSS outcome, CSRF token bypass). "Authentication Bypass" is the questionable one. I'll flag it with confidence "medium" or "high". I'll use "high" — the description explicitly says "did not enforce a block-level edit-permission check", which is authorization, and CVSS PR:H means authenticated. So "Authentication Bypass" is mislabeled. Suggest "Missing Authorization" — hmm, suggested field is "the correct/canonical slug if you know it". Perhaps suggested: "missing-authorization" or "authorization-bypass". I'll say "authorization-bypass". Missing tags? Maybe "concrete-cms" / "concrete5" vendor tag absent. Tags list: XSS, Authentication Bypass, CSRF. Missing tag candidates: "Concrete CMS" (vendor/product) — suggested "concrete-cms", high confidence from description. Also "CWE-862" / "Missing Authorization" technique tag. I'll add "
Oracle Coherence versions 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0 contain a flaw in the Core component that lets an attacker who already holds a high-privileged account and can log on to the host where Coherence runs make unauthorized updates, inserts or deletions against Coherence-accessible data. The CVSS 3.1 base score is only 1.9 (AV:L/AC:H/PR:H/UI:N, integrity-only), reflecting that exploitation demands local logon, elevated privileges and a difficult-to-achieve condition; confidentiality and availability are not impacted. No public exploit code or CISA KEV entry was present in the supplied intelligence, so this is assessed as a low-priority, defense-in-depth issue rather than an urgent patch item. The vendor-reported nature of the record and the presence of an 'Authentication Bypass' tag that conflicts with the PR:H, integrity-only vector are notable data-quality caveats.
Stored cross-site scripting in Concrete CMS 9.5.2 and earlier allows an authenticated user with file-upload rights to embed a javascript: URI in an SVG's xlink:href attribute that survives storage and executes in the browser of any user who opens the uploaded file directly. The flaw only manifests when the non-default 'Reject files containing potentially harmful elements' mode is selected (concrete.file_manager.images.svg_sanitization.action = reject), because in that mode the CMS discarded the output of the enshrined/svg-sanitize pass and relied solely on a narrow built-in blocklist covering <script> and on* handlers. No public exploit code or CISA KEV listing was identified, and the vendor-assigned CVSS v4.0 base score is a low 1.8, reflecting the need for upload privileges, a non-default configuration, and victim interaction.
ManabiPocket for Parents 1.2.3 and earlier — an Android companion app for a Japanese parental school-communication service published by NTT Docomo Business, Inc. — exposes at least one application component that is reachable by other apps on the same device. A malicious app the user has already installed can send a crafted Intent to that component and read sensitive data held by the parental app, making this a local information-disclosure issue rather than a remote compromise. Severity is low (CVSS 4.0 base 1.8) because exploitation requires local code execution, user interaction and additional attack requirements; no public exploit code and no CISA KEV entry were identified at time of analysis, and EPSS data was not supplied.
Confused deputy in PriceTracking in Google Chrome on on iOS prior to 153.0.8010.47 allowed a remote attacker leveraging social engineering to bypass system access restrictions into a privileged page via crafted network traffic. (Chromium security severity: Medium)
Missing authorization in AppManifest in Google Chrome prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)
Race condition in WebAppInstalls in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)
Code injection in XML in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)
A malicious or compromised IMAP server can trigger an out-of-bounds read in the IMAP response parser by sending an untagged '* ID' response, crashing Thunderbird. The affected parsing path is reachable before authentication. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
A maliciously constructed IMAP line could cause an out-of-bounds buffer read. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
A maliciously constructed mail header could lead to multiple fields being parsed as one, or potential memory safety violations. This vulnerability was fixed in Thunderbird 156 and Thunderbird 140.16.
Remote code execution inside the Apache Airflow scheduler is possible through the Apache Kafka provider (apache-airflow-providers-apache-kafka) 1.15.0 to before 2.0.0, which resolves dotted-path strings from a Kafka connection's extra field into Python callables via import_string with no allowlist and hands them to the confluent-kafka client. An authenticated user whose only privilege is editing Airflow connections can thereby execute arbitrary code in the control plane when the non-default Kafka event producer (dag_run_events_enabled or task_instance_events_enabled) is switched on, exceeding the Airflow security model that limits connection-configuration users to code execution on workers. No public exploit code or CISA KEV listing was identified at time of analysis; deployments using Google Managed Kafka are not affected because that code path overwrites any user-supplied oauth_cb, while plain brokers and Amazon MSK are exposed.
Let me synthesize. CVE-2026-86465: Apache Airflow Akeyless provider secrets backend team-scope guard bypass via user-controlled key. Affected: apache-airflow-providers-akeyless before 0.3.1. Fix: 0.3.1. PR: https://github.com/apache/airflow/pull/72646. Similar class to Azure Key Vault, Yandex Lockbox, Amazon secrets backends CVEs. Multi-team deployments using Akeyless secrets backend; single-team not affected. Reachable from ordinary DAG code via Execution API Variables route accepting path-shaped key. DAG author scoped to one team can read secrets belonging to another team — info disclosure (cross-tenant secret access). CVSS: N/A provided. My assessed vector: PR:L (requires DAG author privileges / authenticated user), AV:N, AC:L, UI:N, S:C? Scope change — impacts another team's secrets, but scope change in CVSS terms means authorization scope. Cross-team boundary crossing could be S:C. Impact C:H, I:N, A:N. So CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. That's ~8.3? Let's compute: S:C base... Actually with S:C, PR:L: exploitability = 8.22*AV(0.85)*AC(0.77)*PR(0.68)*UI(0.85) = 8.22*0.85=6.987; *0.77=5.380; *0.68=3.658; *0.85=3.110. Impact: ISCBase = 1 - (1-C)(1-I)(1-A) = 1 - (1-0.56)(1)(1) = 0.56. Scope changed: Impact = 7.52*(ISC-0.029) - 3.25*(ISC-0.02)^15 = 7.52*(0.531) - 3.25*(0.54)^15 ≈ 3.993 - ~0 = 3.993. Base = roundup(min(1.08*(3.110+3.993),10)) = roundup(7.67) = 7.7. Hmm, 7.7 High. Maybe S:C is arguable. Alternatively S:U with C:H gives: Impact = 6.42*0.56 = 3.595; exploitability 3.110; base = roundup(min(1.08*6.705,10)) = roundup(7.24)=7.3. Either way ~7.3-7.7. Actually, "moderate" severity per Apache. Hmm. Apache's own severity is "moderate". But my assessment... I'll go with S:C? Let's think: the vulnerable component is the Akeyless backend; the impact is a different team's secrets. CVSS scope change refers to impact on components beyond the vulnerable component's security authority. The secrets backend... Hmm. This is a classic cross-tenant autho
The Apache Airflow FAB provider (apache-airflow-providers-fab) before 3.9.0 fails to validate the issuer and audience claims of id_tokens presented to its Authentik OAuth login path, so any token that the same Authentik deployment minted for a different client application is accepted by Airflow and authenticates the attacker as the user named in that token. Only deployments running the FAB auth manager with Authentik OAuth against an Authentik instance that also serves other applications are affected — the attacker needs a valid token for one of those other apps, not for Airflow itself. This is a follow-up to CVE-2026-75156, which fixed the identical missing-validation flaw on the Azure AD path in the same file while leaving the Authentik path untouched; upgrade to 3.9.0 or later to remediate. No public exploit code or active-exploitation telemetry was provided in the source data.
Password changes made through the Apache Airflow FAB provider's Admin user-edit PATCH endpoint do not invalidate that user's existing database-backed sessions, so anyone already holding a copy of the victim's session cookie keeps full access to the account after the reset. The flaw affects apache-airflow-providers-fab 3.2.0 up to (but not including) 3.9.0 in deployments using the FAB auth manager with database-backed sessions, and it is a second, independent route to the outcome addressed by CVE-2026-82311 — applying that earlier fix alone does not remediate this endpoint. The advisory rates the issue moderate; no public exploit code, CISA KEV listing, or EPSS score was provided with the intelligence supplied.
Stale database-backed sessions in the Apache Airflow FAB provider (apache-airflow-providers-fab 3.2.0 before 3.9.0) allow an attacker who already holds a copy of a victim's session cookie to keep full access to that account even after the account password is changed, because the Admin user-edit PATCH endpoint never calls the session-invalidation helper. This is a second, independent route to the outcome partially addressed by CVE-2026-82311, so deployments that only applied that earlier fix remain exposed and must additionally upgrade to 3.9.0 or later. No public exploit code or active exploitation is identified from the available data; severity is rated moderate by the vendor.
Deactivated user accounts in the Apache Airflow FAB auth provider (apache-airflow-providers-fab 2.0.0 before 3.9.0) keep working through the Airflow 3 Core API: the password login path correctly rejects a disabled account, but any JWT access token issued before deactivation is still accepted and can be exchanged for a fresh token indefinitely. The result is that an administrative deactivation — typically performed as a containment action against a departing employee or compromised account — silently fails, leaving the account with its original role-scoped access to the Airflow control plane. No signature forgery or privilege escalation is involved; the holder simply replays their own still-valid credential. The issue is rated moderate by the project, with no CVSS vector, CWE, EPSS score, KEV entry, or public exploit code supplied in the available intelligence, and remediation is available in version 3.9.0.
Authentication bypass in the Apache Airflow Keycloak provider (apache-airflow-providers-keycloak) before 0.10.0 lets an attacker who holds valid client credentials for any unrelated confidential client in a shared Keycloak realm obtain a signed Airflow session JWT. Because the provider's token endpoint does not allowlist client ids, credentials that were never issued for Airflow are silently accepted as Airflow login credentials, and Airflow mints a session token for that third-party application's service account. Access is then limited only by what that service account can reach plus any endpoint gated solely on being authenticated, and the endpoint additionally permits unauthenticated credential guessing against Keycloak under Airflow's identity. No public exploit code or CISA KEV entry was identified at time of analysis; severity is rated moderate by the vendor, with the impact bounded by subject-level resource authorization.
The Apache Airflow Keycloak provider (apache-airflow-providers-keycloak before 0.10.0), when running on Airflow 3.3 or later, performs authorization using Keycloak access and refresh tokens read from separate, unsigned cookies while taking the user's identity from the signed Airflow session token, and never verifies that both describe the same subject. Any user
Server-Side Request Forgery (SSRF) in the VMware synchronization feature in Devolutions Server 2026.2.16 and earlier allows a low-privileged authenticated user to obtain other users' credentials and reach internal or cloud-metadata network endpoints via a crafted connection definition submitted for datacenter discovery.
Improper access control in the vault entry listing feature in Devolutions Server 2026.2.16 and earlier allows an authenticated user lacking the view-password permission to obtain cleartext passwords via a request to the entry listing endpoint with password disclosure parameters.
Improper certificate validation in the shared HTTP client used by synchronization and integration features in Devolutions Server 2026.2.16 and earlier allows a network-positioned attacker to intercept and tamper with outbound TLS connections via a spoofed or self-signed certificate.