CVE-2025-54504
Insufficient Granularity of Access Control in AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative
CVSS
—
Sem CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 10 de nov. de 2026 · Última mod.: 10 de nov. de 2026 · CWE-1220
Ainda não há histórico EPSS suficiente.
Insufficient Granularity of Access Control in AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges attacker to write to a trusted region used by AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), potentially resulting in loss of integrity.
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1221697.5 ALT—
——0Insufficient granularity of access control in Windows IKE Extension allows an authorized attacker to perform spoofing locally.11hCVE-2026-57892——
——0Insufficient granularity of access control in the MigTD v2 policy evaluation engine for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow an escalation of privilege. Network adversary with an unauthenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via adjacent access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (high), integrity (high) and availability (none) impacts.8hCVE-2026-1097977.1 ALT17.1%
——5In SAP/astonish, an authenticated user could potentially identify and operate on another team�s sandbox containers because of improper tenant isolation in the legacy Incus sandbox-management API handlers. The affected handlers did not use the tenant-aware session lookup path, allowing cross-tenant container operations such as listing, exposing or proxying, and deleting containers.The issue affects only the legacy Incus backend. Kubernetes and OpenShell deployments are not affected because the relevant Incus-specific handlers are unavailable there.10hCVE-2026-1238038.1 ALT41.9%
——13SuperTokens Core is an open source authentication server. From 10.1.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, loadOptionsById_Transaction and getUserInfoByCredentialId_Transaction perform application-scoped WebAuthn lookups without constraining them to the requested tenant, and WebAuthN.signIn does not verify tenant membership. In a multi-tenant deployment using WebAuthn with a shared user pool, an ordinary user who possesses their own valid passkey in one tenant can submit its assertion to another tenant's sign-in endpoint in the same application and be authenticated there despite having no membership in the target tenant. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.1dCVE-2026-1238028.1 ALT22.9%
——7SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did not satisfy the audience check. When the identity provider uses assertion-level signing, an attacker who has a still-valid IdP-signed assertion naming the victim for any audience and the attacker's own valid assertion for the target audience can combine them because validateSamlResponseAudience accepts an audience from one assertion while extractAllClaims takes the final NameID and attributes from another; response-level signing does not expose this multi-assertion variant. Independently, an assertion from an identity provider configured for the target deployment but issued to another SuperTokens deployment using the shared default saml_sp_entity_id can satisfy the target's audience check. Successful exploitation authenticates the attacker as the victim IdP user. This issue is fixed in versions 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.1dCVE-2026-1048674.3 MÉD24.1%
——7Immich is a high-performance self-hosted photo and video management solution. From 3.0.0 until 3.2.0, the GET /api/admin/users/{id}/calendar-heatmap route in server/src/controllers/user-admin.controller.ts uses the ordinary Permission.UserRead permission without an admin-route requirement, and UserAdminService.getCalendarHeatmap in server/src/services/user-admin.service.ts does not compare the authenticated user with the requested user identifier or perform a separate access check. Any authenticated non-admin user can therefore request another account's upload or capture-date activity heatmap for an arbitrary date range. AssetRepository.getCalendarHeatmap in server/src/repositories/asset.repository.ts filters by owner, date, and deletion state but not visibility, so the returned daily counts and total count include archived and locked assets. The route exposes counts and activity dates but does not return asset metadata or content, and it does not affect integrity or availability. This issue is fixed in version 3.2.0.5d