Search: t**n*e**l s.a. c***t**c***a

In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths

A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission. This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0. Users are recommended to upgrade to version 2.54.0, which fixes the issue.

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.

In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.

In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening.

In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.

A vulnerability in the Linux kernel's ASoC SOF subsystem allowed pointer operations on unconfigured compressed audio streams, leading to a potential divide-by-zero error. This flaw was addressed by validating stream parameters to ensure they are non-zero before performing pointer calculations. The issue affects specific versions of the linux-hwe-edge kernel and has been assigned CVE-2026-46179 with a medium severity rating.

A vulnerability in the Linux kernel's microchip-core-qspi SPI driver was fixed to prevent attempts to transmit data during emulated read-only dual/quad SPI operations. Transmitting data in this scenario can disrupt the transfer because QSPI lacks a dedicated master-out line, potentially causing the transfer to fail. This issue has been addressed in updated Linux kernel releases.

In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.

Learn how attackers exploit automated bot traffic as part of software supply chain attacks to artificially inflate download counters and mask malicious payloads as legitimate. Key takeaways Volume doesn’t equal trust. Packages with numerous versions and high download counts might seem legitimate, but attackers can easily manipulate those metrics. Attackers exploit automated infrastructure. By initially flooding the registry with numerous benign versions of a package, threat actors trigger automatic downloads from mirrors, scanners, and analysis bots, which artificially inflate traffic. Although old download-inflation techniques still work, attackers are developing new sophisticated techniques to deceive developers into installing malicious packages. Downloads count metric Following recent software supply chain attacks in which Tenable has seen attackers steal access tokens and secrets from developer workstations and CI/CD build servers, we started actively monitoring and analyzing npm packages uploaded to the public registry. Initially, we used download counts as a primary metric to determine package relevance. During our monitoring, we identified a recurring anomaly: Brand new packages displayed unusually high download counts within hours of upload. Upon further investigation, we discovered that those packages also had many versions. We found that packages whose content got updated frequently — usually by systematically uploading many new versions for the same package — had an unusually high downloads count. We observed this technique being used deliberately in the wild for the first time in our analysis of the malicious “ambar-src” package , which reached more than 50,000 downloads in three days after attackers uploaded more than 700 versions. We named this technique “download pumping.” Developers and security tools frequently use download counts as one of the metrics to assess a package's legitimacy. Since there is no simple method for determining if a package is legitimate, this artificial inflation effectively disguises the threat. Analysis In the “ambar-src” campaign, threat actors systematically published hundreds of benign versions of the package before introducing the actual malicious payload. Because npm registers each interaction with these updates as traffic, this repetitive version-publishing process achieved two goals: It heavily populated the package’s release history, creating a dense changelog that made the project appear actively maintained and historically legitimate to developers evaluating it. Every time a new version was published, automated systems like repository mirrors and analysis bots automatically downloaded it. Because the attackers systematically uploaded hundreds of versions, they artificially generated a massive wave of automated traffic, inflating the package's download count to more than 50,000 downloads in just three days. From Tenable’s initial analysis, each version uploaded to the npm public registry typically receives between 100 and 150 downloads from automated systems. We verified that fact by running our proof-of-concept (POC) and analyzing the download count. Download pumping PoC To validate these mechanisms, we conducted a POC that replicated the download pumping behavior. We created test packages and systematically published a high volume of new versions to the npm registry. As the npm team stated in their blog , their download stats are naive by design, and they do not put much effort into filtering automated bot traffic. Thus, various repository mirrors, analytical bots, and automated security scanners immediately pulled each new version we uploaded. This validated that an attacker can predictably generate a baseline of downloads entirely through automated publishing, requiring zero organic user interaction. During our POC, we wanted to see how different package properties might affect the automated download volume. We were working under the assumption that packages with postinstall scripts raise the interest level of security scanners. Postinstall scripts are highly interesting to defenders because attackers frequently use these lifecycle hooks to automatically execute malicious payloads the moment a package is installed. Since this is a common malware-deployment technique, automated security scanners prioritize downloading and inspecting packages that have these scripts configured. It is important to note that security scanners don’t have to download the package itself to determine if the npm package has a postinstall script configured, as this data is available in the package metadata in the public registry. For those reasons, we believed that security scanners are more likely to download packages with install scripts configured, as they are more likely to contain malicious code. We deployed three distinct test packages to npm to test our assumption and observed the following results: Version bump only: 135.55 downloads per version This was our baseline test package. We didn’t add or remove any code when publishing a new version, nor did we make any other attempt to make the package look interesting. We simply bumped up the version number each time. Static postinstall script: 141.91 downloads per version This was our second test package, and the first one to have a postinstall script configured, but we didn’t change the script when publishing new versions. Dynamic postinstall script: 158.16 downloads per version In this third test package, we changed the postinstall script every time we bumped up the version. We did this as we believed that security scanners would be more interested in packages whose postinstall script changed, as it could be an indicator of compromise. Graph showing how Tenable’s first POC software package experienced a spike in downloads when we started publishing new versions of it. This data demonstrates a straightforward cause-and-effect: automated infrastructure and security scanners naturally generate more download traffic for packages that exhibit interesting or actively changing behaviors. Other package managers While our research focused specifically on the npm ecosystem, the fundamental mechanics behind this technique are not unique to npm. Other package registries such as PyPI , RubyGems , and NuGet operate with similar automated infrastructure — mirrors, security scanners, and analysis bots — that pull new versions as they are published. Although the specific download amplification and trust metrics may differ across ecosystems, the core principle remains the same: where automated systems react to new publications, there is potential for abuse. Real-world example of download pumping As already stated, we first observed this technique being used in the wild during our analysis of the “ambar-src” package . Let’s look at this in more detail. The attackers created an npm package containing utility code that can be used for legitimate purposes, such as MathUtils, StringUtils and Time functions. The attackers then systematically uploaded 428 legitimate versions of the package in just two hours. The attackers did this to gain initial credibility and attempt to lure developers to use their code. Three days later, the attackers uploaded a new version containing malicious code. By this point, the attackers’ package already had more than 30,000 downloads. In total, the attackers uploaded 724 versions including malicious and legitimate versions. This led to an artificially generated wave of automated traffic, resulting in around 50,000 downloads total. This repetitive version-publishing process successfully inflated the package's download count and created a dense release history, making the project appear historically legitimate before the malware was deployed. Past research on npm download manipulation The manipulation of npm downloads metrics is not a new discovery. In a 2021 research blog , independent developer Andy Richardson showed how prone the npm registry’s download tracking is to abuse, by demonstrating that bad actors can send HTTP requests to a package’s tarball URL to fake downloads. Using automated tools, the researcher successfully drove nearly 1 million spoofed downloads in a single week for a completely unused package. Tenable validated this technique still works in 2026. By sending HTTP requests directly to the URL of the package’s tarball, Tenable successfully inflated a test package’s metric to 17,000 downloads in approximately one hour, using nothing more than a standard office laptop and an internet connection. However, this new version-flooding method we’ve identified offers two distinct advantages: First, it provides amplification, because an attacker gains 100 to 150 automated downloads from repository mirrors for every single version they upload, rather than just one download per HTTP request. Second, systematically publishing these updates populates the release history, creating a dense version log that makes the package appear actively maintained and historically legitimate. Mitigation of supply chain attacks Organizations should not depend on download counts or version histories to determine if a package is legitimate. As we have demonstrated, attackers can easily fake these metrics using automated systems, creating a false sense of trust. Instead, organizations should adopt common industry best practices, such as version pinning and implementing minimum package-age restrictions. These best practices are effective, as security vendors and the open-source community actively monitor these registries and typically detect malicious packages fairly quickly, within a couple of days at most. By enforcing a short waiting period of three to four days before allowing a new package or new version of an existing package into your environment, you allow the community time to identify these threats in the public registry. Once they are detected, they are removed from the public registry, eliminating the risk. It is worth noting that npm is actively working to improve the security of its ecosystem. Recent efforts include adding support for package-age checks directly in the npm CLI, as well as strengthening authentication mechanisms for package maintainers to reduce the risk of account takeovers. While these are meaningful steps in the right direction, the reality is that no single measure can fully prevent malicious code from reaching the public registry. Supply chain attacks will continue to evolve, and organizations should also layer their own defenses rather than rely on the ecosystem alone. For example, organizations can add extra protection for CI/CD build servers by deploying ephemeral CI/CD runners that are destroyed immediately after a single use to prevent malware from lingering. Operating those temporary runners without persistent storage makes it harder for threat actors to save their payloads or establish persistence across different build jobs. Additionally, organizations should enforce least-privilege network access. Restricting outbound traffic makes it harder for malicious payloads running on the build server to reach the open internet to download second-stage malware payloads like “msinit.exe.” So what? Currently, developers are still being hacked through open-source supply chain techniques . The metrics developers and security tools depend on — download counts, version history, maintenance activity — are superficial indicators that, as we have demonstrated, an attacker can manipulat with minimal effort. But the problem runs deeper than fake signals. Even when a package has a legitimate track record with a trusted maintainer behind it, that trust can be compromised overnight. Recent waves of account takeovers, social engineering campaigns, and credential theft targeting established maintainers have shown that a package's history is no guarantee of its current safety, even for legitimate packages. A new version published under a trusted name can carry a malicious payload, and the package manager has no built-in mechanism to catch it. In practice, there is no deterministic method to determine if a new package is malicious or not. Therefore, each package you install and use must be treated like it could be malicious. The meaningful trust signal comes after the fact: from security vendors and the open-source community actively scanning and analyzing packages once they are published. This is exactly why enforcing minimum-age requirements on new packages and new versions is such an effective control . A short waiting period of a few days gives the security community time to detect, flag, and remove threats from the public registry before they ever reach your environment. Organizations that consume packages the moment they are published are accepting risk that is entirely avoidable. Download pumping is ultimately just the initial entry vector for a much larger objective. Attackers using these techniques are generally aiming for one of two outcomes. First, they aim to compromise build servers and CI/CD pipelines. By successfully injecting a malicious dependency into these systems, threat actors achieve “God-mode” over the infrastructure, which can lead to a full compromise of the entire production environment. Second, and even worse, they aim to compromise the developers of highly popular packages. By hijacking a trusted maintainer’s environment, attackers can inject malicious code that thousands of downstream organizations automatically pull, creating a massive cascading effect across the broader software supply chain. How Tenable can help defend against supply chain attacks To defend against supply chain attacks, you need to know exactly what code is running in your environment. The Tenable One Exposure Management Platform and Tenable Nessus can help you build a complete asset inventory of the npm packages used across your organization. Use the following Nessus plugins to build an inventory of the npm modules in your environment: 200172 - Node.js Modules Installed (Windows) 179440 - Node.js Modules Installed (macOS) 178772 - Node.js Modules Installed (Linux) As Tenable continuously analyzes your environment, you get direct visibility into exactly what is installed on your systems. This visibility ensures you can quickly locate and remove compromised packages as soon as a new threat is discovered. Beyond building a complete inventory, organizations also need to actively monitor their environments for live threats. Tenable One Cloud Exposure , a CNAPP, builds on this visibility by continuously monitoring your cloud environment to proactively detect these types of supply chain attacks in real time. Together as part of the Tenable One Exposure Management Platform, these tools proactively detect supply chain attacks across your environments, ensuring your security teams can immediately identify and neutralize malicious activity before attackers can fully compromise your production systems.

CVE-2026-46120 is a use-after-free vulnerability in the Linux kernel's ip6_gre module related to incorrect handling of network namespaces in ip6erspan_changelink(). This flaw causes stale entries in the per-netns hash, leading to a kernel crash (BUG) when the stale netns is destroyed. The issue is reachable from an unprivileged user namespace.

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements. Security Fix(es): * kernel: Bluetooth: MGMT: Fix possible UAFs (CVE-2025-39981) * kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr (CVE-2025-68183) * kernel: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events (CVE-2025-68347) * kernel: libceph: make decode_pool() more resilient against corrupted osdmaps (CVE-2025-71116) * kernel: Linux kernel: Denial of service and memory corruption in RDMA umad (CVE-2026-23243) * kernel: Linux kernel: Use-after-free in traffic control (act_ct) may lead to denial of service or privilege escalation (CVE-2026-23270) * kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() (CVE-2026-23455) * kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408) * kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532) * kernel: net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684) * kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685) * kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup (CVE-2026-43027) * kernel: Bluetooth: MGMT: validate LTK enc_size on load (CVE-2026-43020) * kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq (CVE-2026-43051) * kernel: smb: client: validate the whole DACL before rewriting it in cifsacl (CVE-2026-31709) * kernel: md/bitmap: fix GPF in write_page caused by resize race (CVE-2026-43163) * kernel: netfilter: xt_tcpmss: check remaining length before reading optlen (CVE-2026-43190) * kernel: xfs: fix freemap adjustments when adding xattrs to leaf blocks (CVE-2026-43158) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al (CVE-2025-38653) * kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr (CVE-2025-68183) * kernel: nbd: defer config unlock in nbd_genl_connect (CVE-2025-68366) * kernel: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id (CVE-2025-68724) * kernel: iommu: disable SVA when CONFIG_X86 is set (CVE-2025-71089) * kernel: netfilter: nf_tables: release flowtable after rcu grace period on error (CVE-2026-23392) * kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() (CVE-2026-23455) * kernel: Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold (CVE-2026-31408) * kernel: net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684) * kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685) * kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup (CVE-2026-43027) * kernel: Bluetooth: MGMT: validate LTK enc_size on load (CVE-2026-43020) * kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq (CVE-2026-43051) * kernel: smb: client: validate the whole DACL before rewriting it in cifsacl (CVE-2026-31709) * kernel: Bluetooth: SCO: fix race conditions in sco_sock_connect() (CVE-2026-43023) * kernel: wifi: brcmfmac: validate bsscfg indices in IF events (CVE-2026-43110) * kernel: netfilter: xt_tcpmss: check remaining length before reading optlen (CVE-2026-43190) * kernel: xfs: fix freemap adjustments when adding xattrs to leaf blocks (CVE-2026-43158) * kernel: mm/page_alloc: clear page->private in free_pages_prepare() (CVE-2026-43303) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: can: j1939: j1939_session_new(): fix skb reference counting (CVE-2024-56645) * kernel: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr (CVE-2025-68183) * kernel: mm: thp: deny THP for files on anonymous inodes (CVE-2026-23375) * kernel: netfilter: nf_tables: release flowtable after rcu grace period on error (CVE-2026-23392) * kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() (CVE-2026-23455) * kernel: net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684) * kernel: netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685) * kernel: netfilter: nf_conntrack_helper: pass helper to expect cleanup (CVE-2026-43027) * kernel: io_uring/rsrc: reject zero-length fixed buffer import (CVE-2026-43006) * kernel: Bluetooth: MGMT: validate LTK enc_size on load (CVE-2026-43020) * kernel: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq (CVE-2026-43051) * kernel: Bluetooth: SCO: fix race conditions in sco_sock_connect() (CVE-2026-43023) * kernel: netfilter: ctnetlink: ensure safe access to master conntrack (CVE-2026-43116) * kernel: wifi: brcmfmac: validate bsscfg indices in IF events (CVE-2026-43110) * kernel: netfilter: xt_tcpmss: check remaining length before reading optlen (CVE-2026-43190) * kernel: Linux kernel dpaa2-switch: Kernel memory corruption via out-of-bounds write (CVE-2026-43205) * kernel: xfs: fix freemap adjustments when adding xattrs to leaf blocks (CVE-2026-43158) * kernel: mm/page_alloc: clear page->private in free_pages_prepare() (CVE-2026-43303) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

This vulnerability involves the KVM nSVM feature where an unhandled VMMCALL instruction that is not intercepted by the L1 hypervisor triggers a #UD (Undefined Instruction) exception. The issue is identified in Microsoft product version 3.0. No CVSS score or detailed impact information is provided.

CVE-2026-45932 is a vulnerability in Microsoft software version 3.0 related to improper permissions handling when detaching tcx/netkit programs without providing a program file descriptor. The issue concerns the bpf (Berkeley Packet Filter) subsystem's detach permissions. No CVSS score or detailed technical impact information is available.

### Description Symfony's `#[IsGranted('...')]`, `#[IsSignatureValid]`, and `#[IsCsrfTokenValid(...)]` attributes allow you to define a `methods: [...]` argument to only enforce these checks for the listed HTTP methods and skip them otherwise. E.g. an attribute defining `methods: ['GET']` would be ignored for a `HEAD` request. On the other hand, Symfony's router (and HTTP semantics generally) serves `HEAD` requests using the `GET` handler. Therefore, a controller protected by e.g. `#[IsGranted('ROLE_ADMIN', methods: ['GET'])]` can be reached via `HEAD` with the authorization check silently skipped. Even if the `HEAD` request won't get any response content, response headers leak (`Content-Length`, `Location`, custom headers). Also, the controller still executes and any side effects (DB writes, state changes) occur. ### Resolution When adding `GET` in the `methods` option of these attributes, Symfony now also include the `HEAD` method automatically. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/fa8d5c67aa4b22c9656e3fd7d5c3aa59865bf838) for branch 7.4. ### Credits Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Alexandre Daubois for fixing it.

Anchor is a framework providing several convenient developer tools for writing Solana programs. From 1.0.0 to before 1.0.2, an logic error causes anchor programs to accept any program id when requiring the system program id, causing false assumptions resulting in potential arbitrary cpi in programs that invoke system program instructions. In the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>, the id of T is compared with Pubkey::default() to check whether anchor should allow any executable account, or a specific account, because when no T is supplied, T defaults to (), which implements Id::id() by returning Pubkey::default(). This results in T = () and T = System (which has Pubkey::default() as the id) having the same behavior, both allow any executable account. Programs built with anchor assume that the anchor runtime verifies passed in programs of type Program<'a, System> are in fact the system program. This false assumption can lead to arbitrary CPI or payment bypassing when programs try making CPI calls to the system program using the passed in system program due to the fact that the attacker can pass in any program instead of the system program. This vulnerability is fixed in 1.0.2.

A coordinated smishing operation spanning 19 countries across Europe, the Americas, and the Caucasus has been exposed, originating from fraudulent SMS messages impersonating Romania's government payment portal Ghișeul.ro. Investigation revealed 1,628 malicious URLs linked by a single 128-character campaign identifier, targeting government portals, traffic police departments, postal services including DPD and SEUR, tax authorities, and telecommunications providers like T-Mobile and Vodafone. The infrastructure utilizes 32 backend IP addresses distributed across Tencent Cloud, Alibaba Cloud, Cloudflare CDN, and ALEXHOST Moldova. Threat actors employ two distinct phishing templates: a Vue.js single-page application and a Bootstrap-based clone, executing a four-stage credential harvesting process that collects complete payment card details through fabricated traffic fines, toll payments, and delivery notifications.

Campaign#smishing#government impersonationUnited States+18