| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insufficient Verification of Data Authenticity in Nagios Fusion 4.1.8 and earlier and Nagios XI 5.7.5 and earlier allows for Escalation of Privileges or Code Execution as root via vectors related to an untrusted update package to upgrade_to_latest.sh. |
| The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default. |
| A vulnerability has been identified in APOGEE PXC Compact (BACnet) (All versions < V3.5.5), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.20), APOGEE PXC Modular (BACnet) (All versions < V3.5.5), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.20), Nucleus NET (All versions < V5.2), Nucleus ReadyStart V3 (All versions < V2012.12), Nucleus Source Code (All versions), PLUSCONTROL 1st Gen (All versions), TALON TC Compact (BACnet) (All versions < V3.5.5), TALON TC Modular (BACnet) (All versions < V3.5.5). Initial Sequence Numbers (ISNs) for TCP connections are derived from an insufficiently random source. As a result, the ISN of current and future TCP connections could be predictable. An attacker could hijack existing sessions or spoof future ones. |
| pass through 1.7.3 has a possibility of using a password for an unintended resource. For exploitation to occur, the user must do a git pull, decrypt a password, and log into a remote service with the password. If an attacker controls the central Git server or one of the other members' machines, and also controls one of the services already in the password store, they can rename one of the password files in the Git repository to something else: pass doesn't correctly verify that the content of a file matches the filename, so a user might be tricked into decrypting the wrong password and sending that to a service that the attacker controls. NOTE: for environments in which this threat model is of concern, signing commits can be a solution. |
| An unsigned-library issue was discovered in ProlinOS through 2.4.161.8859R. This OS requires installed applications and all system binaries to be signed either by the manufacturer or by the Point Of Sale application developer and distributor. The signature is a 2048-byte RSA signature verified in the kernel prior to ELF execution. Shared libraries, however, do not need to be signed, and they are not verified. An attacker may execute a custom binary by compiling it as a shared object and loading it via LD_PRELOAD. |
| ServiceStack before 5.9.2 mishandles JWT signature verification unless an application has a custom ValidateToken function that establishes a valid minimum length for a signature. |
| Yandex Browser for Android 20.8.4 allows remote attackers to perform SOP bypass and addresss bar spoofing |
| An issue was discovered in Xen through 4.14.x allowing x86 guest OS users to cause a denial of service (data corruption), cause a data leak, or possibly gain privileges because an AMD IOMMU page-table entry can be half-updated. |
| Bash injection vulnerability and bypass of signature verification in Rostelecom CS-C2SHW 5.0.082.1. The camera reads firmware update configuration from SD card file vc\version.json. fw-sign parameter and from this configuration is directly inserted into a bash command. Firmware update is run automatically if there is special file on the inserted SD card. |
| An issue was discovered in ClamXAV 3 before 3.1.1. A malicious actor could use a properly signed copy of ClamXAV 2 (running with an injected malicious dylib) to communicate with ClamXAV 3's helper tool and perform privileged operations. This occurs because of inadequate client verification in the helper tool. |
| Monal before 4.9 does not implement proper sender verification on MAM and Message Carbon (XEP-0280) results. This allows a remote attacker (able to send stanzas to a victim) to inject arbitrary messages into the local history, with full control over the sender and receiver displayed to the victim. |
| The Linux kernel through 5.8.13 does not properly enforce the Secure Boot Forbidden Signature Database (aka dbx) protection mechanism. This affects certs/blacklist.c and certs/system_keyring.c. |
| An issue was discovered in Foxit Reader and PhantomPDF before 4.1 on macOS. Because the Hardened Runtime protection mechanism is not applied to code signing, code injection (or an information leak) can occur. |
| An issue was discovered in API/api/Version in Damstra Smart Asset 2020.7. Cross-origin resource sharing trusts random origins by accepting the arbitrary 'Origin: example.com' header and responding with 200 OK and a wildcard 'Access-Control-Allow-Origin: *' header. |
| Dex is a federated OpenID Connect provider written in Go. In Dex before version 2.27.0 there is a critical set of vulnerabilities which impacts users leveraging the SAML connector. The vulnerabilities enables potential signature bypass due to issues with XML encoding in the underlying Go library. The vulnerabilities have been addressed in version 2.27.0 by using the xml-roundtrip-validator from Mattermost (see related references). |
| Kirby is a CMS. In Kirby CMS (getkirby/cms) before version 3.3.6, and Kirby Panel before version 2.5.14 there is a vulnerability in which the admin panel may be accessed if hosted on a .dev domain. In order to protect new installations on public servers that don't have an admin account for the Panel yet, we block account registration there by default. This is a security feature, which we implemented years ago in Kirby 2. It helps to avoid that you forget registering your first admin account on a public server. In this case – without our security block – someone else might theoretically be able to find your site, find out it's running on Kirby, find the Panel and then register the account first. It's an unlikely situation, but it's still a certain risk. To be able to register the first Panel account on a public server, you have to enforce the installer via a config setting. This helps to push all users to the best practice of registering your first Panel account on your local machine and upload it together with the rest of the site. This installation block implementation in Kirby versions before 3.3.6 still assumed that .dev domains are local domains, which is no longer true. In the meantime, those domains became publicly available. This means that our installation block is no longer working as expected if you use a .dev domain for your Kirby site. Additionally the local installation check may also fail if your site is behind a reverse proxy. You are only affected if you use a .dev domain or your site is behind a reverse proxy and you have not yet registered your first Panel account on the public server and someone finds your site and tries to login at `yourdomain.dev/panel` before you register your first account. You are not affected if you have already created one or multiple Panel accounts (no matter if on a .dev domain or behind a reverse proxy). The problem has been patched in Kirby 3.3.6. Please upgrade to this or a later version to fix the vulnerability. |
| Open Zaak is a modern, open-source data- and services-layer to enable zaakgericht werken, a Dutch approach to case management. In Open Zaak before version 1.3.3 the Cross-Origin-Resource-Sharing policy in Open Zaak is currently wide open - every client is allowed. This allows evil.com to run scripts that perform AJAX calls to known Open Zaak installations, and the browser will not block these. This was intended to only apply to development machines running on localhost/127.0.0.1. Open Zaak 1.3.3 disables CORS by default, while it can be opted-in through environment variables. The vulnerability does not actually seem exploitable because: a) The session cookie has a `Same-Site: Lax` policy which prevents it from being sent along in Cross-Origin requests. b) All pages that give access to (production) data are login-protected c) `Access-Control-Allow-Credentials` is set to `false` d) CSRF checks probably block the remote origin, since they're not explicitly added to the trusted allowlist. |
| Python oic is a Python OpenID Connect implementation. In Python oic before version 1.2.1, there are several related cryptographic issues affecting client implementations that use the library. The issues are: 1) The IdToken signature algorithm was not checked automatically, but only if the expected algorithm was passed in as a kwarg. 2) JWA `none` algorithm was allowed in all flows. 3) oic.consumer.Consumer.parse_authz returns an unverified IdToken. The verification of the token was left to the discretion of the implementator. 4) iat claim was not checked for sanity (i.e. it could be in the future). These issues are patched in version 1.2.1. |
| Opencast before versions 8.9 and 7.9 disables HTTPS hostname verification of its HTTP client used for a large portion of Opencast's HTTP requests. Hostname verification is an important part when using HTTPS to ensure that the presented certificate is valid for the host. Disabling it can allow for man-in-the-middle attacks. This problem is fixed in Opencast 7.9 and Opencast 8.8 Please be aware that fixing the problem means that Opencast will not simply accept any self-signed certificates any longer without properly importing them. If you need those, please make sure to import them into the Java key store. Better yet, get a valid certificate. |
| An issue was discovered in the ALFA Windows 10 driver 1030.36.604 for AWUS036ACH. The WEP, WPA, WPA2, and WPA3 implementations accept fragmented plaintext frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary data frames independent of the network configuration. |
