The internet is broken right now.

Improper input validation in Bixby prior to version 4.0.85.6 allows privileged local attackers to launch arbitrary activity.

Other Device

AMI APTIOV contains vulnerabilities in BIOS where privileged users may cause the “Out-of-Bounds Read” by local access. Successful exploitation of this vulnerability may lead to a denial of service during firmware update processing, such as a crash or failed update if the out-of-bounds read hits unmapped memory. It could also impact Confidentiality, and Availability.

Memory safety Device

A time-of-check to time-of-use race condition in the SafeNet Authentication Client (SAC) SACSrv log-cleanup function can allow an authenticated, non-administrator local user to redirect a privileged file deletion operation outside the intended log directory.  This issue affects SAC releases up to and including 10.9 R3 GA (build 10.9.7449).

Auth & access Device

In multiple locations, there is a possible use-after-free due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

A weakness has been identified in kubescape up to 4.0.15. Impacted is the function GetWriter of the file core/pkg/resultshandling/printer/printresults.go of the component Output. Executing a manipulation of the argument outputFile can lead to permission issues. The attack requires local access. Upgrading to version 4.0.16 is recommended to address this issue. This patch is called d90f77314c7d4f2b53cf2425844bde2315bd26d2. Upgrading the affected component is advised.

Disclosure Device

In handleMessage of UsbDeviceManager.java, there is a possible lock-screen bypass due to a logic error in the code. This could lead to physical information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Disclosure Device Google Android

API keys, credentials, and configuration parameters embedded in the MatchPoint APK, which can be extracted through reverse engineering. The vendor distinguishes the extracted elements from Google Maps and Firebase keys that must remain on the client side and considers them project identifiers, not authentication secrets. The impact depends on the capabilities and restrictions of each exposed element.

Auth & access Device

The report details a heap Use-After-Free (UAF) vulnerability within the `android.hardware.automotive.evs-default` HAL service, stemming from unsynchronized access to an `std::unordered_map`. An unprivileged application with access to the EVS manager can trigger this UAF by making concurrent calls to `setExtendedInfo` and `getExtendedInfo`, potentially enabling code execution within the privileged HAL process.

Memory safety Device Google Android

Samsung mTower lacks access control for TA sessions, allowing a Normal World application to open TA sessions and invoke their commands, or use a close existing sessions if thier identifiers are known, The impact depends on the affected TA.

Other Device

Processing a malformed RRC message leads to an out-of-bounds read, resulting in a denial-of-service condition.

Denial of service Device

VeraCrypt provides disk encryption with strong security based on TrueCrypt. Prior to 1.26.30, the Unix, macOS, and FreeBSD serialization paths in src/Platform/Serializer.cpp and src/Volume/VolumePassword.cpp accept untrusted length and count values when deserializing data that can cross from the unprivileged GUI or CLI to the root CoreService helper. Serializer::DeserializeWString allocates floor(size / sizeof(wchar_t)) elements but reads size bytes, so a non-aligned size can overflow the heap allocation. VolumePassword::Deserialize accepts PasswordSize values larger than the fixed 128-byte PasswordBuffer, allowing downstream DataPtr() and Size() consumers such as the KDF to read beyond the buffer. DeserializeString, DeserializeWString, and the string and wide-string list readers also lack allocation and collection bounds, which can exhaust memory, and a zero-length DeserializeString can access an empty vector. Windows uses a different path, and the immediate CoreService pipe writer is the same-user parent process, so the documented exposure is a local defense-in-depth boundary rather than a remote attack. This issue is fixed in 1.26.30.

Memory safety Device

In resolveAidConflictLocked of RegisteredAidCache.java, there is a possible permission bypass due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Auth & access Device Google Android

In multiple locations, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

Use of hard-coded cryptographic key vulnerability in Johnson Controls Kantech Entrapass allows Padding Oracle Crypto Attack. This issue affects Kantech Entrapass: before 9.20.

Crypto Device

In multiple functions in multiple locations, there is a possible execution of sensitive USSD codes due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Other Device Google Android

IBM Db2 Genius Hub 1.1.2, 1.1.3, 1.1.4, 1.1.5 could allow a local attacker to cause a denial of service due to uncontrolled resource consumption.

Denial of service Device IBM Agentics

In __pkvm_guest_relinquish_to_host of mem_protect.c, there is a possible out-of-bounds write due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

The RTIO streaming completion callback adxl345_process_fifo_samples_cb() in drivers/sensor/adi/adxl345/adxl345_stream.c clamps the amount of FIFO data it will report (read_len = MIN(fifo_bytes, buf_avail)) to the space actually returned by rtio_sqe_rx_buf(), but then queues one 6-byte bus read per hardware FIFO entry at consecutive offsets from read_buf, bounded by the device-reported entry count rather than by the clamp. When the allocated buffer is smaller than a full batch, the driver writes up to 186 bytes past the end of the allocation; a companion defect left data->fifo_total_bytes un-reset at batch start, so an aborted or errored chain could leave a stale write offset that pushes the next batch's writes out of bounds as well. A short buffer is an expected, first-class outcome of the RTIO allocator: rtio_block_pool_alloc() walks the requested size down one block at a time until a contiguous run is available, and the driver only demands sizeof(struct adxl345_fifo_data) + 6 bytes as its minimum. Any streaming configuration whose mempool block granularity is smaller than a full FIFO batch (204 bytes) — for example the sensor shell's RTIO_DEFINE_WITH_MEMPOOL(sensor_read_rtio, 8, 8, 32, 64, 4) used by sensor stream <dev> on fifo_wm incl, or the 16-byte-block streaming example in the documentation — takes this path whenever the pool is fragmented or the consuming thread falls behind. The out-of-bounds writes are performed by the I2C/SPI RTIO backend (DMA on many SoCs) into the shared RTIO block pool, corrupting neighbouring live buffers or, for a pool smaller than one batch, memory beyond the pool itself. The written bytes are accelerometer samples and the destination follows the allocation, so there is no controllable corruption primitive: the realistic impact is silent corruption of other RTIO consumers' data or a crash. Reaching it requires a board with an interrupt-wired ADXL345 built with CONFIG_ADXL345_STREAM, plus buffer-pool starvation, which a co-resident local workload can induce but which also occurs spontaneously under load; there is no network, USB or radio path to this code.

Memory safety Device

MCUboot's serial-recovery image-upload handler bs_upload() in boot/boot_serial/src/boot_serial.c declares const struct flash_area *fap = NULL and assigns it only via flash_area_open() part-way through the function. Two early validation failures (goto out_invalid_data) — a CBOR map that fails to decode, or an upload packet missing the off/data members — branch past the open while fap is still NULL, then fall into the shared epilogue. In MCUBOOT_ENC_IMAGES builds that epilogue unconditionally calls boot_handle_enc_fw(fap), which reaches boot_image_load_header() and flash_area_read() and dereferences the NULL flash_area. The defect is reachable pre-authentication: the trigger is the very first serial-recovery upload command carrying a malformed payload. The guarding conditions are default-true on a fresh recovery session — img_num, curr_off and img_size are zero-initialized statics, so curr_off == img_size and the primary-slot test both hold. It requires a non-default build: encrypted images (MCUBOOT_ENC_IMAGES / Zephyr CONFIG_BOOT_ENCRYPT_IMAGE) together with an active serial-recovery transport, on the Zephyr or Mynewt port (the two that build both boot/boot_serial/src/boot_serial.c and boot_serial_encryption.c with MCUBOOT_ENC_IMAGES). The impact is a transient denial of service of the bootloader during recovery. fap is a hard NULL rather than an attacker-controlled value, so there is no memory-corruption or information-leak primitive and image authentication is unaffected. Whether the dereference faults is platform-dependent — on targets where address 0x0 is mapped readable flash the read merely returns an error and execution continues, while targets that trap NULL (MPU / null-pointer-exception detection) take a hard fault. Because serial recovery is unauthenticated by design and already permits the console attacker to write the secondary slot, the added capability is only a low-value transient crash. The related unconditional flash_area_close(fap) call in the same epilogue is a safe no-op on the ports that reach it, so it does not contribute to the dereference. The affected ports are the Zephyr port — boot/zephyr/CMakeLists.txt compiles boot_serial.c under CONFIG_MCUBOOT_SERIAL and boot_serial_encryption.c under CONFIG_BOOT_ENCRYPT_IMAGE — and the Mynewt port, whose mcuboot_config.h defines MCUBOOT_SERIAL unconditionally and MCUBOOT_ENC_IMAGES under any BOOTUTIL_ENCRYPT_ syscfg, with boot/boot_serial/pkg.yml declaring no explicit source list so the whole directory is built. The Espressif port is not affected**: it compiles boot_serial.c but not boot_serial_encryption.c, and defines no MCUBOOT_ENC_IMAGES, so the #ifdef MCUBOOT_ENC_IMAGES block containing the call is preprocessed away. The NuttX, Cypress and Mbed ports do not build boot_serial.c at all.

Memory safety Device

A vulnerability was detected in Yoosee GM8135S Camera 21.00.01.36. Affected is an unknown function of the component Secure Boot. Performing a manipulation results in improper verification of cryptographic signature. The attack needs to be approached locally. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Crypto Device

VLC for Android before 3.7.2 contains a confused-deputy file overwrite vulnerability in FileUtils.getUri() that trusts content URIs based only on the com.fsck.k9.attachmentprovider or gmail-ls authority. A co-installed app without permissions can declare these authorities and send a crafted VIEW intent to the exported StartActivity, making VLC write attacker-chosen content under an attacker-chosen name in the shared Download directory, overwriting other apps' files when VLC holds All files access.

Other Device

This vulnerability exists in the iRA 2.0 and iRA.ev mobile applications due to improper implementation of SSL certificate pinning in the network security configuration, resulting in ineffective certificate pinning controls. An attacker positioned to intercept network traffic could exploit this vulnerability to intercept or modify communications between the application and its backend services.

Crypto Device

In sendAnomalyProfile of ProfilingService.java, there is a possible path traversal issue due to path traversal. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Disclosure Device Google Android

In MCUboot's serial-recovery encrypted-image support (boot/boot_serial/src/boot_serial_encryption.c), decrypt_image_inplace() and boot_image_validate_encrypted() each keep a stack-local struct boot_status. boot_enc_load() writes the plaintext per-image AES key into its enckey[] field. Neither function cleared this structure before returning. In addition, a decrypt failure inside the per-sector loop of decrypt_image_inplace() returned early and skipped the total_out: cleanup, which left the expanded AES key context (enc_data) on the stack as well. The error paths of boot_image_validate_encrypted() similarly skipped boot_enc_zeroize(). The affected code is built when encrypted images (MCUBOOT_ENC_IMAGES, Zephyr CONFIG_BOOT_ENCRYPT_IMAGE) are combined with serial recovery. It runs when an encrypted image is uploaded to the primary slot over the recovery protocol, and when the image list or state is queried while an encrypted image is in the secondary slot. After these functions return, the image's AES content key remains in dead stack memory. An attacker who can later read device RAM, for example through a debug port or retained RAM, can recover it. This weakens the confidentiality of image-encryption keys within the bootloader trust boundary. A recovered key exposes the plaintext of the encrypted firmware image it protects. The device's long-term private decryption key is not exposed. No remote or recovery-protocol channel that returns this memory is known, so exploitation requires a separate memory-read capability.

Other Device

When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT_USE_TINYCRYPT), bootutil_aes_ctr_drop() in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc_aes_key_sched_struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here. As a result, boot_state_clear(), which boot_go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot_data state. This is the case after an encrypted upgrade in single-image builds, where boot_enc_zeroize() is not called. boot_decrypt_key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT_ENC_IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port. The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil_wipe_memory().

Crypto Device

The vulnerability is a Use-After-Free (UAF) in the EVS AIDL HAL, arising from a data race on an unsynchronized `std::weak_ptr` within `EvsEnumerator::openCamera()`. Specifically, concurrent calls from a privileged UID (e.g., `AID_AUTOMOTIVE_EVS`) can cause a torn `weak_ptr` state, leading to a virtual call through a freed object's vtable at `cameraObj->getCameraInfo(&desc)`. This allows for potential arbitrary code execution within the `hal_evs_default` process.

Memory safety Device Google Android

In rb_cpu_init of trace.c, there is a possible out-of-bounds read due to an incorrect bounds check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

OOB read vulnerability in the peripheral module. Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Memory safety Device

Cleartext storage of sensitive information in memory vulnerability in Johnson Controls Kantech Entrapass allows Retrieve Embedded Sensitive Data. This issue affects Kantech Entrapass: before 9.20.

Disclosure Device

A vulnerability to perform a privilege escalation attack on the server as a non-admin user.

Crypto Device

Cleartext storage of sensitive information in memory vulnerability in Johnson Controls EasyIO Neo IOManager and Tools Installer allows Retrieve Embedded Sensitive Data. This issue affects EasyIO Neo IOManager and Tools Installer: 1.1.0.0.

Disclosure Device

In multiple locations, there is a possible denial of service due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Denial of service Device Google Android

In multiple locations, there is a possible permission bypass due to an uncaught exception. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Other Device Google Android

Database backups are vulnerable to offline attacks. Backups created using a version prior to the patched version are still vulnerable. AXIS Camera Station Pro automatically creates one more such backup for recovery purpose when the update is applied. Delete all these backups and change the credentials stored in AXIS Camera Station Pro.

Crypto Device

In multiple locations, there is a possible out-of-bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

In multiple functions of AllowBindAppWidgetActivity.java, there is a possible misunderstanding of reject/consent actions due to misleading or insufficient UI. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

Other Device Google Android

In multiple locations, there is a possible way to trick a user into accepting a permission due to a tapjacking/overlay attack. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

Other Device Google Android

In multiple functions of MmiUtils.java, there is a possible risk of USSD/MMI code execution due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

Code execution Device Google Android

In arm_lpae_split_blk_unmap of io-pgtable-arm-common.c, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

In insertInternal of MmsProvider.java, there is a possible multiuser isolation issue due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Auth & access Device Google Android

In setOemUnlockAllowedByUser of OemLockService.java, there is a possible way to bypass FRP due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Auth & access Device Google Android

In multiple functions of NfcService.java, there is a possible permission bypass due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Auth & access Device Google Android

In multiple locations, there is a possible method for a primary user to disable secure nfc on other full users due to insufficient isolation between Android users. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Auth & access Device Google Android

Permission control vulnerability in the Bluetooth module. Impact: Successful exploitation of this vulnerability may affect availability.

Other Device

In multiple locations, there is a possible denial of service due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.

Denial of service Device Google Android

In InputDispatcher::flushSensor of InputDispatcher.cpp, there is a possible denial of service due to a logic error in the code. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Denial of service Device Google Android

In setApplicationRestrictions of DevicePolicyManagerService.java, there is a possible denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Denial of service Device Google Android

In deserialize of legacy.rs, there is a possible denial of service due to a missing bounds check. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety Device Google Android

In getTouchOcclusionMode of WindowState.java, there is a possible tapjacking issue due to a tapjacking/overlay attack. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.

Disclosure Device Google Android

A potential improper certificate validation vulnerability was reported in Lenovo Smart Camera C33, distributed exclusively in the Chinese market, that could allow an adjacent user to intercept or manipulate network communications.

Crypto Device