Chiara Fliegner

**Name of the Vulnerable Software and Affected Versions** SENAITE.CORE versions 2.0.0 through 2.6.0 **Description** An unauthenticated remote code execution issue exists in the SENAITE JSON API due to a chain of missing authorization and unsafe evaluation of input. The state-changing routes in `src/bika/lims/jsonapi/update.py`, including `update`, `update many`, `remove`, `doActionFor`, `doActionFor many`, and `getusers`, do not enforce the `senaite.core: Access JSON API` permission. Additionally, the `set fields from request` function in `src/bika/lims/jsonapi/init.py` passes raw request values for `RecordsField` and `RecordField` instances to the `eval()` function before write-permission checks are performed. An anonymous attacker can discover the `bika setup` object identifier via the `@@uuid` view and send a malicious payload to the `/@@API/update` endpoint. This allows the execution of arbitrary Python code within the Zope worker process. The same unsafe evaluation pattern is also present in `src/senaite/core/browser/fields/record.py` and `src/senaite/core/browser/fields/records.py`. Successful exploitation can lead to the exposure or modification of laboratory data, files, and accounts, or complete service disruption. **Recommendations** For versions 2.0.0 through 2.6.0: - Add the `AccessJSONAPI` permission check to every state-changing route in `src/bika/lims/jsonapi/` to ensure authorization is verified before processing requests. - Replace the `eval()` function with `json.loads()` in `src/bika/lims/jsonapi/ init .py`, `src/senaite/core/browser/fields/record.py`, and `src/senaite/core/browser/fields/records.py` to prevent arbitrary code execution. - Remove the `IDisableCSRFProtection` inheritance from `class ISenaiteCore` in `src/senaite/core/interfaces/ init .py` to re-enable automatic CSRF write-detection.

**Name of the Vulnerable Software and Affected Versions** epa4all-client versions prior to 1.2.5 **Description** Any network-reachable caller can write arbitrary documents to any patient's electronic health record accessible by the institution's SMC-B card. In misconfigured deployments, such as those following the production Docker example in the README, this can be exploited from the local network without credentials. **Recommendations** Update to version 1.2.5. Use network policies or proxies to enforce service-to-service authentication via mTLS (Mutual Transport Layer Security), which is a process where both parties in a communication link authenticate each other. Run the service in an isolated network namespace, such as a Kubernetes sidecar. Implement a service-mesh with corresponding policies.

**Name of the Vulnerable Software and Affected Versions** epa4all-client versions prior to 1.2.2 **Description** An attacker positioned on the network path between the ePA service and the Konnektor can present any TLS certificate, such as self-signed, expired, or those with an incorrect Common Name (CN), to intercept all SOAP traffic. This interception may expose patient identifiers (KVNR), SMC-B card operations involving authentication and signing, document content, and credential exchanges. **Recommendations** Update to version 1.2.2. Use the library directly instead of the REST wrapper as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** epa4all-client versions prior to 1.2.2 **Description** An attacker capable of performing a Man-in-the-Middle (MITM) attack on the TLS connection between the client and the Identity Provider (IDP) within the Telematik Infrastruktur network can substitute a forged discovery document. This document redirects the `uri puk idp enc` and `uri puk idp sig` variables to URLs controlled by the attacker. Consequently, the client encrypts the SMC-B-signed challenge response using the attacker's encryption key and sends it via a POST request to the attacker's authentication endpoint, allowing the capture of signed authentication material. **Recommendations** Update to version 1.2.2.

**Name of the Vulnerable Software and Affected Versions** epa4all-client (affected versions not specified) **Description** A signature bypass exists in the `isTrusted()` function of the `SignedPublicKeysTrustValidatorImpl` class. The ECDSA signature verification process discards the boolean return value of the `Signature.verify()` function. Although the system performs certificate chain validation, OCSP checks, and signature algorithm setup, it fails to verify if the signature actually matches, resulting in the function returning true for any structurally valid signature. **Recommendations** Update to the version that includes the fix provided in pull request #34.