Total
36333 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-24422 | 1 Phpmyfaq | 1 Phpmyfaq | 2026-06-17 | N/A | 5.3 MEDIUM |
| phpMyFAQ is an open source FAQ web application. In versions 4.0.16 and below, multiple public API endpoints improperly expose sensitive user information due to insufficient access controls. The OpenQuestionController::list() endpoint calls Question::getAll() with showAll=true by default, returning records marked as non-public (isVisible=false) along with user email addresses, with similar exposures present in comment, news, and FAQ APIs. This information disclosure vulnerability could enable attackers to harvest email addresses for phishing campaigns or access content that was explicitly marked as private. This issue has been fixed in version 4.0.17. | |||||
| CVE-2026-24420 | 1 Phpmyfaq | 1 Phpmyfaq | 2026-06-17 | N/A | 6.5 MEDIUM |
| phpMyFAQ is an open source FAQ web application. Versions 4.0.16 and below allow an authenticated user without the dlattachment permission to download FAQ attachments due to a incomprehensive permissions check. The presence of a right key is improperly validated as proof of authorization in attachment.php. Additionally, the group and user permission logic contains a flawed conditional expression that may allow unauthorized access. This issue has been fixed in version | |||||
| CVE-2026-24414 | 1 Icinga | 1 Icinga Powershell Framework | 2026-06-17 | N/A | 5.5 MEDIUM |
| The Icinga PowerShell Framework provides configuration and check possibilities to ensure integration and monitoring of Windows environments. In versions prior to 1.13.4, 1.12.4, and 1.11.2, permissions of the Icinga for Windows `certificate` directory grant every user read access, which results in the exposure of private key of the Icinga certificate for the given host. All installations are affected. Versions 1.13.4, 1.12.4, and 1.11.2 contains a patch. Please note that upgrading to a fixed version of Icinga for Windows will also automatically fix a similar issue present in Icinga 2, CVE-2026-24413. As a workaround, the permissions can be restricted manually by updating the ACL for the given folder `C:\Program Files\WindowsPowerShell\modules\icinga-powershell-framework\certificate` (and `C:\ProgramData\icinga2\var` to fix the issue for the Icinga 2 agent as well) including every sub-folder and item to restrict access for general users, only allowing the Icinga service user and administrators access. | |||||
| CVE-2026-24324 | 1 Sap | 1 Businessobjects Business Intelligence Platform | 2026-06-17 | N/A | 6.5 MEDIUM |
| SAP BusinessObjects Business Intelligence Platform (AdminTools) allows an authenticated attacker with user privileges to execute a specific query in AdminTools that could cause the Content Management Server (CMS) to crash, rendering the CMS partially or completely unavailable and resulting in the denial of service of the Content Management Server (CMS). Successful exploitation impacts system availability, while confidentiality and integrity remain unaffected. | |||||
| CVE-2026-24321 | 1 Sap | 1 Commerce Cloud | 2026-06-17 | N/A | 5.3 MEDIUM |
| SAP Commerce Cloud exposes multiple API endpoints to unauthenticated users, allowing them to submit requests to these open endpoints to retrieve sensitive information that is not intended to be publicly accessible via the front-end. This vulnerability has a low impact on confidentiality and does not affect integrity and availability. | |||||
| CVE-2026-24314 | 1 Sap | 2 S\/4hana Uiapfi70, S\/4hana Uis4h | 2026-06-17 | N/A | 4.3 MEDIUM |
| Under certain conditions SAP S/4HANA (Manage Payment Media) allows an authenticated attacker to access information which would otherwise be restricted. This could cause low impact on confidentiality of the application while integrity and availability are not impacted. | |||||
| CVE-2026-24306 | 1 Microsoft | 1 Azure Front Door | 2026-06-17 | N/A | 9.8 CRITICAL |
| Improper access control in Azure Front Door (AFD) allows an unauthorized attacker to elevate privileges over a network. | |||||
| CVE-2026-24241 | 1 Nvidia | 1 Delegated License Service | 2026-06-17 | N/A | 4.3 MEDIUM |
| NVIDIA Delegated Licensing Service for all appliance platforms contains a vulnerability where an attacker could exploit an improper authentication issue. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-24015 | 1 Apache | 1 Iotdb | 2026-06-17 | N/A | 9.8 CRITICAL |
| A vulnerability in Apache IoTDB. This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7. Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue. | |||||
| CVE-2026-23896 | 1 Futo | 1 Immich | 2026-06-17 | N/A | 7.2 HIGH |
| immich is a high performance self-hosted photo and video management solution. Prior to version 2.5.0, API keys can escalate their own permissions by calling the update endpoint, allowing a low-privilege API key to grant itself full administrative access to the system. Version 2.5.0 fixes the issue. | |||||
| CVE-2026-23836 | 1 Hotcrp | 1 Hotcrp | 2026-06-17 | N/A | 9.9 CRITICAL |
| HotCRP is conference review software. A problem introduced in April 2024 in version 3.1 led to inadequately sanitized code generation for HotCRP formulas which allowed users to trigger the execution of arbitrary PHP code. The problem is patched in release version 3.2. | |||||
| CVE-2026-23777 | 1 Dell | 2 Data Domain Operating System, Powerprotect Data Domain | 2026-06-17 | N/A | 4.3 MEDIUM |
| Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) of Feature Release versions 7.7.1.0 through 8.5, LTS2025 release version 8.3.1.0 through 8.3.1.20, LTS2024 release versions 7.13.1.0 through 7.13.1.50, contain an exposure of sensitive information to an unauthorized actor vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to information exposure. | |||||
| CVE-2026-23660 | 1 Microsoft | 1 Windows Admin Center | 2026-06-17 | N/A | 7.8 HIGH |
| Improper access control in Azure Portal Windows Admin Center allows an authorized attacker to elevate privileges locally. | |||||
| CVE-2026-23654 | 1 Microsoft | 1 Zero-shot-scfoundation | 2026-06-17 | N/A | 8.8 HIGH |
| Dependency on vulnerable third-party component in GitHub Repo: zero-shot-scfoundation allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2026-23417 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix constant blinding for PROBE_MEM32 stores BPF_ST | BPF_PROBE_MEM32 immediate stores are not handled by bpf_jit_blind_insn(), allowing user-controlled 32-bit immediates to survive unblinded into JIT-compiled native code when bpf_jit_harden >= 1. The root cause is that convert_ctx_accesses() rewrites BPF_ST|BPF_MEM to BPF_ST|BPF_PROBE_MEM32 for arena pointer stores during verification, before bpf_jit_blind_constants() runs during JIT compilation. The blinding switch only matches BPF_ST|BPF_MEM (mode 0x60), not BPF_ST|BPF_PROBE_MEM32 (mode 0xa0). The instruction falls through unblinded. Add BPF_ST|BPF_PROBE_MEM32 cases to bpf_jit_blind_insn() alongside the existing BPF_ST|BPF_MEM cases. The blinding transformation is identical: load the blinded immediate into BPF_REG_AX via mov+xor, then convert the immediate store to a register store (BPF_STX). The rewritten STX instruction must preserve the BPF_PROBE_MEM32 mode so the architecture JIT emits the correct arena addressing (R12-based on x86-64). Cannot use the BPF_STX_MEM() macro here because it hardcodes BPF_MEM mode; construct the instruction directly instead. | |||||
| CVE-2026-23416 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm/mseal: update VMA end correctly on merge Previously we stored the end of the current VMA in curr_end, and then upon iterating to the next VMA updated curr_start to curr_end to advance to the next VMA. However, this doesn't take into account the fact that a VMA might be updated due to a merge by vma_modify_flags(), which can result in curr_end being stale and thus, upon setting curr_start to curr_end, ending up with an incorrect curr_start on the next iteration. Resolve the issue by setting curr_end to vma->vm_end unconditionally to ensure this value remains updated should this occur. While we're here, eliminate this entire class of bug by simply setting const curr_[start/end] to be clamped to the input range and VMAs, which also happens to simplify the logic. | |||||
| CVE-2026-23405 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: apparmor: fix: limit the number of levels of policy namespaces Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource. Hard cap policy namespaces to the same depth as user namespaces. | |||||
| CVE-2026-23404 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: apparmor: replace recursive profile removal with iterative approach The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes. Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove Replace the recursive __aa_profile_list_release() approach with an iterative approach in __remove_profile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion. | |||||
| CVE-2026-23402 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Only WARN in direct MMUs when overwriting shadow-present SPTE Adjust KVM's sanity check against overwriting a shadow-present SPTE with a another SPTE with a different target PFN to only apply to direct MMUs, i.e. only to MMUs without shadowed gPTEs. While it's impossible for KVM to overwrite a shadow-present SPTE in response to a guest write, writes from outside the scope of KVM, e.g. from host userspace, aren't detected by KVM's write tracking and so can break KVM's shadow paging rules. ------------[ cut here ]------------ pfn != spte_to_pfn(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:3069 at mmu_set_spte+0x1e4/0x440 [kvm], CPU#0: vmx_ept_stale_r/872 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 872 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mmu_set_spte+0x1e4/0x440 [kvm] Call Trace: <TASK> ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- | |||||
| CVE-2026-23395 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found. | |||||