| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In Eclipse BaSyx Go Components versions up to and including 1.1.3, ABAC-enabled deployments match `ROUTE` access rules against the fully decoded request path, while the router routes on the raw, still encoded path. An encoded slash (`%2F`) inside a path value is a segment separator for the access check but part of the value for the router, so a request can match a narrow `ROUTE` rule while the handler returns a different, larger resource.
An authenticated caller whose rules grant READ only on parts of a resource can therefore read the whole resource. In the DPP API, a rule such as `/v1/dpps/*/elements/*`, meant to grant only passport elements, also grants the complete passport whose identifier contains `/elements/`. In the Submodel Repository, AAS Repository and AAS Environment, a rule such as `/submodels/*/submodel-elements/*/attachment`, meant to grant only file attachments, also grants the complete element whose stored idShort contains `%2F`.
The issue is fixed in Eclipse BaSyx Go Components v1.1.4. |
| C-Kermit from 6.0.192 before 11.1.515 contains a file collision protection bypass that allows malicious senders to append data to existing files by marking transfers as RESEND. The gattr() function in ckcfn3.c clears the REJECT discard flag and switches to APPEND without a RECEIVE CONFIRM prompt, letting attackers modify files such as shell startup files. |
| C-Kermit 11.0.506 before 11.1.515 contains a RECEIVE CONFIRM bypass vulnerability that allows malicious Kermit servers to write unrequested files without prompting by abusing recursive GET root computation in ckcfns.c. Attackers can send files such as .ssh/authorized_keys or shell startup files under the current directory, which rq_under_root() accepts silently, enabling persistent access or code execution. |
| C-Kermit 6.0.192 before 11.1.515 contains a remote code execution vulnerability that allows Kermit clients to run shell commands on servers with host commands disabled by abusing REMOTE QUERY evaluation. Attackers can send a REMOTE QUERY invoking the command function, or define a macro via REMOTE ASSIGN and call execute to reach RUN, bypassing the nopush restriction and DISABLE HOST. |
| In multiple locations, there is a possible way to dump secure cache lines into non-secure memory on warm reset due to a missing permission check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. |
| A incorrect authorization vulnerability in Fortinet FortiAuthenticator 8.0.0 through 8.0.3, FortiAuthenticator 6.6.0 through 6.6.10 may allow an attacker to bypass authentication and gain unauthorized access. Full impersonation however requires the attacker to obtain pre-required id and data via other means. |
| A incorrect authorization vulnerability in Fortinet FortiAuthenticator 8.0.0 through 8.0.3, FortiAuthenticator 6.6.0 through 6.6.10 may allow an unauthenticated attacker to bypass authorization checks and gain unauthorized access to restricted functionality. |
| Audition is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed. |
| Incorrect authorization in Extensions in Google Chrome prior to 157.0.8103.78 allowed a remote attacker leveraging social engineering to execute arbitrary code inside the sandbox via a crafted Chrome extension. (Chromium security severity: High) |
| Incorrect authorization in FileSystem in Google Chrome prior to 157.0.8103.78 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In gittuf 0.10.0 through 0.15.0, when a minimum threshold global rule and a policy rule protect the same namespace, verification gives the global rule's check over all trusted users in the policy precedence over the policy rule's own authorized users. A user listed in the policy file but not authorized by the policy rule, or fewer users than the rule's threshold, can make changes to the protected namespace that pass verification. |
| In gittuf 0.4.0 through 0.16.0, when a policy update appears within the range of reference state log entries being verified, verification checks only the root of trust signatures of the new policy and not the signatures of its other metadata (rule files). A user trusted to push to the repository who bypasses gittuf policy apply and writes the policy reference and reference state log directly can make an invalid policy apply during verification, weakening or strengthening the rules for later changes. The update is still recorded in the reference state log. |
| In gittuf 0.10.0 through 0.17.0, the verification workflow does not load policy updates that are propagated from an upstream (controller) repository and recorded in the reference state log after the first entry being verified. Only the propagated policy in effect at the start of verification is applied, so later controller changes to global rules, such as threshold requirements and force-push blocks, are ignored and changes that these rules should block pass verification. |
| In gittuf before 0.18.0, verification of file protection rules uses the quoted, escaped pathnames that Git prints by default for files with special characters (for example non-ASCII characters) instead of the raw paths. Such paths do not match patterns like file:internal/*, so the files are treated as unprotected, and a user who is not authorized by a file protection rule can change a protected file whose name contains special characters and still pass verification. |
| Dell PowerStore contains an Improper Authorization vulnerability. An authenticated user could exploit this vulnerability, potentially leading to privilege escalation to administrator. |
| An incorrect authorization vulnerability in the Security Advisor in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote attackers to read specific files. |
| Psono Server Community Edition versions 1.12.6 through 7.5.0 and Psono Server Enterprise Edition before 7.5.1 do not require accepted group membership when authorizing deletion of group share-rights. The DELETE /share/right/ endpoint checks for a membership matching the target group, the authenticated user, and share_admin=True, but omits accepted=True. An authenticated remote attacker who has been invited to a group with share-admin privileges, and who knows a group share-right UUID, can therefore delete that group's share-right record without accepting the invitation or after declining it. Pending invitations have accepted=None, while declined invitations retain accepted=False and the share_admin flag. Deletion revokes the group's access to the affected share and its contained secrets for all accepted group members, without deleting the underlying data or disclosing secret contents. The issue was fixed in version 7.5.1 of both editions, released on 2026-10-13. |
| In Eclipse BaSyx Go Components versions up to and including 1.1.2, ABAC-enabled deployments of the Submodel Repository and the AAS Environment return Submodel Elements that the caller is not authorized to read from `GET /submodels/{submodelIdentifier}/submodel-elements`.
If an access rule grants READ on a single Submodel Element through a `$sme` `REFERABLE` object, the list route returns every element of that Submodel, including its value, as soon as one element matches the caller's rules. The single-element route and the full Submodel read enforce the same rule and deny access to the other elements. An authenticated caller with a READ grant for one element of a Submodel can therefore read all other elements of that Submodel.
The issue is fixed in Eclipse BaSyx Go Components v1.1.3. |
| In cpm_mbox_power_ctrl_sswrp of cpm_mbox.c, there is a possible permission bypass due to a precondition check failure. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. |
| In Eclipse BaSyx Go Components versions up to and including 1.1.2, ABAC-enabled deployments of the Submodel Repository and the AAS Environment do not apply an access rule's `FILTERLIST` fragment filters to single Submodel reads.
`GET /submodels` removes the fields that a rule's `FILTERLIST` hides, but `GET /submodels/{submodelIdentifier}` and `GET /submodels/{submodelIdentifier}/$metadata` return them unfiltered. An authenticated caller with READ access to a Submodel can therefore read fields that the access rules hide from them, for example `supplementalSemanticIds` keys that name the other parties allowed to read the Submodel.
If versioning is enabled (`history.mode` set to `api` or `audit`), `GET /submodels/{submodelIdentifier}/$history` and `GET /shells/{aasIdentifier}/$history` in the Submodel Repository, AAS Repository and AAS Environment return the complete stored version without applying the rule's formula or fragment filters. A caller whose rules grant READ on these routes can read fields that the access rules hide, and Submodels and Asset Administration Shells that the direct read does not return to them at all.
The issue is fixed in Eclipse BaSyx Go Components v1.1.3. |
