🚨 CVE-2026-57175
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the SAML backend accepted SAML responses on the Assertion Consumer Service endpoint without verifying that they matched a previously issued `AuthnRequest`. Applications using SAML account association could allow an attacker with a valid account on a trusted IdP to link the attacker's SAML identity to a logged-in victim's local account. The attacker could then authenticate through SAML and gain access to the victim's account. The issue affects applications using the SAML backend together with authenticated account association. The issue has been fixed in version 5.0.0 by validating SAML responses against stored `AuthnRequest` IDs.
🎖@cveNotify
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the SAML backend accepted SAML responses on the Assertion Consumer Service endpoint without verifying that they matched a previously issued `AuthnRequest`. Applications using SAML account association could allow an attacker with a valid account on a trusted IdP to link the attacker's SAML identity to a logged-in victim's local account. The attacker could then authenticate through SAML and gain access to the victim's account. The issue affects applications using the SAML backend together with authenticated account association. The issue has been fixed in version 5.0.0 by validating SAML responses against stored `AuthnRequest` IDs.
🎖@cveNotify
GitHub
Improper SAML Authentication in social-auth-core
### Impact
The SAML backend accepted SAML responses on the Assertion Consumer Service endpoint without verifying that they matched a previously issued `AuthnRequest`.
Applications using SAML ...
The SAML backend accepted SAML responses on the Assertion Consumer Service endpoint without verifying that they matched a previously issued `AuthnRequest`.
Applications using SAML ...
🚨 CVE-2026-57176
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the Vend OAuth2 backend used only the numeric Vend user_id as the social-auth UID. When multiple Vend shops authenticate through the same application, users from different shops with the same internal Vend user ID could collide in the social-auth association table. A user from one shop could then be authenticated as the local account previously associated with the same numeric user ID from another shop. The issue affects applications using the Vend OAuth2 backend with more than one Vend shop. Version 5.0.0 patches the issue.
🎖@cveNotify
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the Vend OAuth2 backend used only the numeric Vend user_id as the social-auth UID. When multiple Vend shops authenticate through the same application, users from different shops with the same internal Vend user ID could collide in the social-auth association table. A user from one shop could then be authenticated as the local account previously associated with the same numeric user ID from another shop. The issue affects applications using the Vend OAuth2 backend with more than one Vend shop. Version 5.0.0 patches the issue.
🎖@cveNotify
GitHub
Account Takeover via Identity Binding Flaw in Vend Backend
### Impact
The Vend OAuth2 backend used only the numeric Vend `user_id` as the social-auth UID.
When multiple Vend shops authenticate through the same application, users from different shops ...
The Vend OAuth2 backend used only the numeric Vend `user_id` as the social-auth UID.
When multiple Vend shops authenticate through the same application, users from different shops ...
🚨 CVE-2026-57177
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the LoginRadius backend did not validate OAuth state during the authentication flow. Applications using this backend were vulnerable to login CSRF. An attacker could cause a victim's browser session to complete authentication using an attacker-controlled LoginRadius token, making the victim authenticated as the attacker's LoginRadius identity. The issue affects only applications using the LoginRadius backend. The issue has been fixe in version 5.0.0 by enabling callback state validation for the LoginRadius backend.
🎖@cveNotify
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the LoginRadius backend did not validate OAuth state during the authentication flow. Applications using this backend were vulnerable to login CSRF. An attacker could cause a victim's browser session to complete authentication using an attacker-controlled LoginRadius token, making the victim authenticated as the attacker's LoginRadius identity. The issue affects only applications using the LoginRadius backend. The issue has been fixe in version 5.0.0 by enabling callback state validation for the LoginRadius backend.
🎖@cveNotify
GitHub
Login CSRF via Missing State Parameter in LoginRadius Backend
### Impact
The LoginRadius backend did not validate OAuth state during the authentication flow.
Applications using this backend were vulnerable to login CSRF. An attacker could cause a victim...
The LoginRadius backend did not validate OAuth state during the authentication flow.
Applications using this backend were vulnerable to login CSRF. An attacker could cause a victim...
🚨 CVE-2026-57178
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the `vk-app` backend accepted VK application callback data without verifying the callback signature when the `auth_key` parameter was omitted. Applications using this backend could treat unsigned attacker-controlled data as a verified VK identity. An attacker could choose callback fields such as `viewer_id`, `access_token`, `api_id`, and `api_result`, potentially allowing authentication as an arbitrary VK user ID. The issue affects only applications using the `vk-app` backend. The issue has been fixed in version 5.0.0 by requiring `auth_key` to be present and valid before callback data is trusted.
🎖@cveNotify
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, the `vk-app` backend accepted VK application callback data without verifying the callback signature when the `auth_key` parameter was omitted. Applications using this backend could treat unsigned attacker-controlled data as a verified VK identity. An attacker could choose callback fields such as `viewer_id`, `access_token`, `api_id`, and `api_result`, potentially allowing authentication as an arbitrary VK user ID. The issue affects only applications using the `vk-app` backend. The issue has been fixed in version 5.0.0 by requiring `auth_key` to be present and valid before callback data is trusted.
🎖@cveNotify
GitHub
VK App backend accepts unsigned callback data when auth_key is missing
### Impact
The `vk-app` backend accepted VK application callback data without verifying the callback signature when the `auth_key` parameter was omitted.
Applications using this backend could...
The `vk-app` backend accepted VK application callback data without verifying the callback signature when the `auth_key` parameter was omitted.
Applications using this backend could...
🚨 CVE-2026-82164
Dell Trusted Device Client, versions prior to 8.1.359.0, contain an Incorrect Permission Assignment for Critical Resource vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information tampering.
🎖@cveNotify
Dell Trusted Device Client, versions prior to 8.1.359.0, contain an Incorrect Permission Assignment for Critical Resource vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information tampering.
🎖@cveNotify
🚨 CVE-2026-85491
Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone.
Catalyst::Seal replaces the dispatcher's prepare_action with a version that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from.
A path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running.
The memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain.
🎖@cveNotify
Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone.
Catalyst::Seal replaces the dispatcher's prepare_action with a version that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from.
A path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running.
The memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain.
🎖@cveNotify
🚨 CVE-2026-97230
IO::Socket::SSL::SelfCertificate versions 1.00 for Perl contains malware which executes Python code from an obfuscated URL.
The generate_certificate runs a Python script saved as a certificate file. The pyhton script attempts to retrieve code from a hardcoded http URL that is obfuscated with base64 encoding and run the response body directly.
The impact is that arbitrary code can be invoked as the user, without a dropped script being saved on the affected host.
The releases have no test scripts nor build hooks. The intention may have been to trigger the payload after installation.
The dropper script is in lib/Crypt/SelfCertificate/sample/cert.pem.
This is similar to CVE-2026-95831 for the module Crypt::SelfCertificate.
The SHA-256 digests of the files are
ba24ee8ec3b7f47f65bed62e16fb413ace50653cf44bd8ea90914390922831e0 IO-Socket-SSL-SelfCertificate-1.00.tar.gz
821d38830e5eb8607738421c25ac25f59fff02a6ab67daa32fbd020429454dac IO-Socket-SSL-SelfCertificate-1.00/lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem
d483cb7b23b7271cb11cf242bff4a2e1c02df0b9525eb0429abeea8961c399d5 IO-Socket-SSL-SelfCertificate-1.00-upload.tar.gz
🎖@cveNotify
IO::Socket::SSL::SelfCertificate versions 1.00 for Perl contains malware which executes Python code from an obfuscated URL.
The generate_certificate runs a Python script saved as a certificate file. The pyhton script attempts to retrieve code from a hardcoded http URL that is obfuscated with base64 encoding and run the response body directly.
The impact is that arbitrary code can be invoked as the user, without a dropped script being saved on the affected host.
The releases have no test scripts nor build hooks. The intention may have been to trigger the payload after installation.
The dropper script is in lib/Crypt/SelfCertificate/sample/cert.pem.
This is similar to CVE-2026-95831 for the module Crypt::SelfCertificate.
The SHA-256 digests of the files are
ba24ee8ec3b7f47f65bed62e16fb413ace50653cf44bd8ea90914390922831e0 IO-Socket-SSL-SelfCertificate-1.00.tar.gz
821d38830e5eb8607738421c25ac25f59fff02a6ab67daa32fbd020429454dac IO-Socket-SSL-SelfCertificate-1.00/lib/IO/Socket/SSL/SelfCertificate/sample/cert.pem
d483cb7b23b7271cb11cf242bff4a2e1c02df0b9525eb0429abeea8961c399d5 IO-Socket-SSL-SelfCertificate-1.00-upload.tar.gz
🎖@cveNotify
🚨 CVE-2026-84283
Secure Folder 1.2 stores files selected for its password-protected vault as unencrypted files in the Android shared-storage tree. A local application or file manager that has access to the relevant shared-storage path can enumerate, copy, and open those files without authenticating to Secure Folder.
🎖@cveNotify
Secure Folder 1.2 stores files selected for its password-protected vault as unencrypted files in the Android shared-storage tree. A local application or file manager that has access to the relevant shared-storage path can enumerate, copy, and open those files without authenticating to Secure Folder.
🎖@cveNotify
Fluidattacks
Secure Folder 1.2 - Plaintext vault files in shared storage bypass the PIN gate | Fluid Attacks
CVE-2026-84283: Secure Folder 1.2 stores files selected for its password-protected vault as unencrypted files in the Android shared-storage tree. A local application or file manager that has access to the relevant shared-storage path can enumerate, copy,…
🚨 CVE-2026-85082
Root Browser Classic 3.3.0 passes the path of a selected SQLite database to an operating-system shell without safely separating the filename from the command.
🎖@cveNotify
Root Browser Classic 3.3.0 passes the path of a selected SQLite database to an operating-system shell without safely separating the filename from the command.
🎖@cveNotify
Fluidattacks
Root Browser Classic 3.3.0 - OS command injection through crafted SQLite filenames | Fluid Attacks
CVE-2026-85082: Root Browser Classic passes the path of a selected SQLite database to an operating-system shell without safely separating the filename from the command.
🚨 CVE-2026-92288
Lemonldap::NG::Portal versions from 2.20.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow unauthenticated OAuth2 token introspection because checkEndPointAuthenticationCredentials does not verify the client secret of a public Relying Party.
checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the authentication method deduced from the request, client_secret_basic or client_secret_post. introspection() rejects a caller only when that method is missing or none, so a request carrying a public client_id and an arbitrary or empty secret passes the endpoint's authentication check.
An attacker who holds an access token and knows the client_id of any public Relying Party can confirm the token is active and read its metadata, including scope, audience, expiry and the sub claim. The sub claim is computed with the calling Relying Party's user identifier attribute, so an attacker can translate a user identifier from one Relying Party to another, defeating per-client and pseudonymous identifiers.
🎖@cveNotify
Lemonldap::NG::Portal versions from 2.20.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow unauthenticated OAuth2 token introspection because checkEndPointAuthenticationCredentials does not verify the client secret of a public Relying Party.
checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the authentication method deduced from the request, client_secret_basic or client_secret_post. introspection() rejects a caller only when that method is missing or none, so a request carrying a public client_id and an arbitrary or empty secret passes the endpoint's authentication check.
An attacker who holds an access token and knows the client_id of any public Relying Party can confirm the token is active and read its metadata, including scope, audience, expiry and the sub claim. The sub claim is computed with the calling Relying Party's user identifier attribute, so an attacker can translate a user identifier from one Relying Party to another, defeating per-client and pseudonymous identifiers.
🎖@cveNotify
GitLab
Version 2.21.6 LTS · LemonLDAP NG / lemonldap-ng · GitLab
Bugs:
🚨 CVE-2026-92289
Lemonldap::NG::Portal versions from 2.23.0 before 2.23.4 for Perl allow a PKCE bypass for public Relying Parties in "PKCE or secret" mode because checkEndPointAuthenticationCredentials does not verify the client secret.
With oidcRPMetaDataOptionsRequirePKCE set to 2, the authorization endpoint issues a code even when the request carries no code_challenge, and token() admits the exchange as long as a challenge was stored or an authentication method was returned for the caller. checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the method deduced from the request, so any Basic or form credential satisfies the secret branch. validatePKCEChallenge() then passes, because neither a challenge nor a verifier is present.
An attacker who intercepts an authorization code issued to a public Relying Party can exchange it for the user's access, ID and refresh tokens by replaying the client_id with an arbitrary secret, which is the attack PKCE prevents. Dynamic client registration creates every Relying Party in this mode.
🎖@cveNotify
Lemonldap::NG::Portal versions from 2.23.0 before 2.23.4 for Perl allow a PKCE bypass for public Relying Parties in "PKCE or secret" mode because checkEndPointAuthenticationCredentials does not verify the client secret.
With oidcRPMetaDataOptionsRequirePKCE set to 2, the authorization endpoint issues a code even when the request carries no code_challenge, and token() admits the exchange as long as a challenge was stored or an authentication method was returned for the caller. checkEndPointAuthenticationCredentials() skips the secret comparison for a Relying Party marked public and still returns the method deduced from the request, so any Basic or form credential satisfies the secret branch. validatePKCEChallenge() then passes, because neither a challenge nor a verifier is present.
An attacker who intercepts an authorization code issued to a public Relying Party can exchange it for the user's access, ID and refresh tokens by replaying the client_id with an arbitrary secret, which is the attack PKCE prevents. Dynamic client registration creates every Relying Party in this mode.
🎖@cveNotify
GitLab
Version 2.23.4 · LemonLDAP NG / lemonldap-ng · GitLab
Bugs:
🚨 CVE-2026-95811
Lemonldap::NG::Handler versions from 2.0.0 before 2.16.10, from 2.17.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow an equivalent spelling of a path to bypass the locationRules that restrict it.
The handler matches each vhost's locationRules regular expressions against REQUEST_URI, the raw request line, while the web server routes on the path it has already percent-decoded and normalized. A request that percent-encodes a character of the path, inserts dot segments, or doubles a slash therefore reaches the protected resource under a URI that no rule regexp matches, and the vhost's default rule decides access. Deny rules, identity and group conditions, and unprotect and skip rules are bypassed alike.
Only a vhost whose default rule is more permissive than its other rules is affected. An authenticated user then reaches any URL a locationRules regexp was meant to restrict, but gains no more than that default rule already grants.
🎖@cveNotify
Lemonldap::NG::Handler versions from 2.0.0 before 2.16.10, from 2.17.0 before 2.21.6, from 2.22.0 before 2.23.4 for Perl allow an equivalent spelling of a path to bypass the locationRules that restrict it.
The handler matches each vhost's locationRules regular expressions against REQUEST_URI, the raw request line, while the web server routes on the path it has already percent-decoded and normalized. A request that percent-encodes a character of the path, inserts dot segments, or doubles a slash therefore reaches the protected resource under a URI that no rule regexp matches, and the vhost's default rule decides access. Deny rules, identity and group conditions, and unprotect and skip rules are bypassed alike.
Only a vhost whose default rule is more permissive than its other rules is affected. An authenticated user then reaches any URL a locationRules regexp was meant to restrict, but gains no more than that default rule already grants.
🎖@cveNotify
🚨 CVE-2026-78394
The Link Library WordPress plugin before 7.9.6 does not sanitize a user-supplied destination folder before writing a generated image to disk, allowing users with the Contributor role and above to create directories and write or overwrite image files anywhere the web server can write, including outside the site's document root.
The written file name is always numeric with a fixed image extension, so executable code cannot be planted this way.
🎖@cveNotify
The Link Library WordPress plugin before 7.9.6 does not sanitize a user-supplied destination folder before writing a generated image to disk, allowing users with the Contributor role and above to create directories and write or overwrite image files anywhere the web server can write, including outside the site's document root.
The written file name is always numeric with a fixed image extension, so executable code cannot be planted this way.
🎖@cveNotify
WPScan
Link Library < 7.9.6 - Contributor+ Path Traversal via 'filepath' Parameter
See details on Link Library < 7.9.6 - Contributor+ Path Traversal via 'filepath' Parameter CVE 2026-78394. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-78397
The Link Library WordPress plugin before 7.9.6 does not validate the destination of a user-supplied URL before falling back to an unprotected fetch when its safe request is rejected, allowing unauthenticated visitors to make the site issue requests to hosts on its internal network and to learn from the response whether an internal service answered.
Versions below 7.8.8 are covered by CVE-2025-68600; this entry covers 7.8.8 through 7.9.5, where that fix was incomplete. Exploitation requires the site owner to have published the Link Library WordPress plugin before 7.9.6's public link submission form with reciprocal-link validation enabled.
🎖@cveNotify
The Link Library WordPress plugin before 7.9.6 does not validate the destination of a user-supplied URL before falling back to an unprotected fetch when its safe request is rejected, allowing unauthenticated visitors to make the site issue requests to hosts on its internal network and to learn from the response whether an internal service answered.
Versions below 7.8.8 are covered by CVE-2025-68600; this entry covers 7.8.8 through 7.9.5, where that fix was incomplete. Exploitation requires the site owner to have published the Link Library WordPress plugin before 7.9.6's public link submission form with reciprocal-link validation enabled.
🎖@cveNotify
WPScan
Link Library < 7.9.6 - Unauthenticated SSRF via Reciprocal Link Validation
See details on Link Library < 7.9.6 - Unauthenticated SSRF via Reciprocal Link Validation CVE 2026-78397. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-93477
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.
Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.
Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.
The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.
This issue affects ash: from 2.17.15 before 3.33.11.
🎖@cveNotify
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.
Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.
Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.
The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.
This issue affects ash: from 2.17.15 before 3.33.11.
🎖@cveNotify
🚨 CVE-2026-97846
Keycloak provides a feature called mTLS holder-of-key binding which ensures that a token can only be used by the client that originally requested it by binding it to their digital certificate. A flaw was discovered where the new Standard Token Exchange V2 feature does not check for this certificate. This allows an attacker with stolen client credentials to obtain a standard, unrestricted token that bypasses these security protections.
🎖@cveNotify
Keycloak provides a feature called mTLS holder-of-key binding which ensures that a token can only be used by the client that originally requested it by binding it to their digital certificate. A flaw was discovered where the new Standard Token Exchange V2 feature does not check for this certificate. This allows an attacker with stolen client credentials to obtain a standard, unrestricted token that bypasses these security protections.
🎖@cveNotify
Redhat
CVE-2026-97846 - Red Hat Customer Portal
CVE Details App
🚨 CVE-2026-96448
A flaw was found in the Fine-Grained Admin Permissions (FGAP v2) feature of Keycloak, an identity and access management solution. The issue occurs when the system checks if a delegated administrator has permission to assign a specific role to a user. Because the check does not look inside composite roles to see what other permissions they contain, an administrator with limited rights can assign a role that secretly includes full administrative control. This allows the attacker to gain complete management access over the entire realm.
🎖@cveNotify
A flaw was found in the Fine-Grained Admin Permissions (FGAP v2) feature of Keycloak, an identity and access management solution. The issue occurs when the system checks if a delegated administrator has permission to assign a specific role to a user. Because the check does not look inside composite roles to see what other permissions they contain, an administrator with limited rights can assign a role that secretly includes full administrative control. This allows the attacker to gain complete management access over the entire realm.
🎖@cveNotify
Redhat
CVE-2026-96448 - Red Hat Customer Portal
CVE Details App
🚨 CVE-2026-6082
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/payment-methods' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/payment-methods' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
www.incibe.es
Stored Cross-Site Scripting in StockAgile by Novadigits technologies
INCIBE has coordinated the disclosure of seven medium-severity vulnerabilities affecting the API and t
🚨 CVE-2026-6083
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '
/inventory/configuration/pricing-tiers' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '
/inventory/configuration/pricing-tiers' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
www.incibe.es
Stored Cross-Site Scripting in StockAgile by Novadigits technologies
INCIBE has coordinated the disclosure of seven medium-severity vulnerabilities affecting the API and t
🚨 CVE-2026-6084
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/variants' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/variants' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
www.incibe.es
Stored Cross-Site Scripting in StockAgile by Novadigits technologies
INCIBE has coordinated the disclosure of seven medium-severity vulnerabilities affecting the API and t
🚨 CVE-2026-6085
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/serial-number-types' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
Stored Cross-Site Scripting (XSS) vulnerability in StockAgile API and management panel. The vulnerability is present on the server side in REST endpoint '/inventory/configuration/serial-number-types' that allow the injection and persistence of malicious JavaScript code through parameters such as ‘code’, ‘name’, and other text fields. The scripts that are entered are not filtered or validated correctly before being displayed on the web panel that authenticated users can access. Exploiting this vulnerability could allow a remote, previously authenticated attacker to execute arbitrary JavaScript code.
🎖@cveNotify
www.incibe.es
Stored Cross-Site Scripting in StockAgile by Novadigits technologies
INCIBE has coordinated the disclosure of seven medium-severity vulnerabilities affecting the API and t