Search: probe, s.a. de c.v

Other noteworthy stories that might have slipped under the radar: Android TV botnet Popa linked to Israeli firm, Velvet Ant maintained decade-long stealth, unpatched GCP Config Connector flaw enables takeover. The post In Other News: Apple Patches Beats Eavesdropping Flaw, DOT Closes Delta CrowdStrike Probe, AWS Continuum appeared first on SecurityWeek .

Discover how continuous control validation in Tenable One can improve your CTEM program by filtering out alert noise and factoring in your active cyber defenses. Focus your team on accessible and exploitable attack paths. Key takeaways: With vulnerability exploitation ranking as the top initial access vector and frontier AI accelerating vulnerability discovery, organizations must shift from managing theoretical cyber risks to validating actual, accessible exposure. Tenable One maps active security controls including EDR, MFA, and firewalls directly onto potential attack paths, allowing teams to automatically deprioritize weaknesses that existing defenses already neutralize. Ingesting penetration testing results via the Tenable One Open Connector allows organizations to layer real-world attack simulations over real-time exposure insights to identify toxic risk combinations that threaten critical assets. Your security tools probably indicate you have thousands, perhaps tens or hundreds of thousands, of vulnerabilities across your environment. Maybe your tools prioritize these vulnerabilities based on CVSS scores or other criteria, but how do you know which vulnerabilities combine with other preventable security risks, like misconfigured cloud buckets and identity weaknesses, to create attack paths threat actors could realistically traverse? How do you validate which vulnerabilities an existing security control mitigates? You need this context to distinguish the real risks from the theoretical ones to ensure your team focuses on remediating what matters most. The work of validating, prioritizing, and remediating vulnerabilities alongside other security weaknesses to understand the true exposure they create has become much more urgent, as frontier AI models accelerate vulnerability discovery. In this environment, the traditional patch-based defense model will get crushed. Moreover, defenders cannot afford inaccurate decision-making and wasted remediation work that addresses low-priority vulnerabilities. They desperately need the context and validation that a continuous threat exposure management (CTEM) program provides. This is why security leaders are evolving their vulnerability management programs to exposure management programs. Exposure management allows you to continually assess your attack surface, prioritize risks , and orchestrate automated remediation of security weaknesses at machine speed. Exposure management also helps validate which exposures attackers can actually reach by understanding the accessibility and exploitability of an attack path. It uses validation to shift your organization from managing theoretical risks to executing on actual exposure. What is exposure validation in CTEM? Validation is one of the five steps in the CTEM lifecycle. It is the process of providing consistent, continuous, and automated evidence of an attack’s feasibility. It stress-tests your defenses against real-world attack conditions, using your own environment’s controls and configurations to confirm whether an exposure is genuinely reachable and exploitable. Validation moves security from a reactive “patch everything” mindset to a preemptive, evidence-based exposure strategy . It continuously confirms which weaknesses your existing defenses have already blocked and surfaces the ones that demand immediate attention. Expanded CTEM validation capabilities in Tenable One Validation isn’t new to Tenable: we’ve been using validation techniques in Tenable solutions for more than 25 years. Tenable developed nearly 3,000 direct check plugins to actively probe a vulnerability and prove its exploitability in situations where software version detection isn’t sufficient for our high-accuracy standards. These plugins actually mimic attack techniques and monitor the target’s response to confirm the presence of the vulnerability. What is new in Tenable One is the addition of continuous control validation in the platform. By factoring in your active security controls, Tenable One helps eliminate the noise of theoretically exposed assets that are functionally blocked from exploitation. Security teams can visually map their active prevention and detection controls directly onto potential attack paths, automatically prioritizing weaknesses that existing controls already neutralize. Analysts can also filter top attack paths based on the presence of security controls and whether you can prevent attack chains for faster triage and investigation. Common control validation examples include: Endpoint detection and response (EDR) tools that block Local Security Authority Subsystem Service (LSASS) memory dump tools used to harvest credentials. Multi-factor authentication (MFA) methods that prevent unauthorized access via password guessing , password spraying , or credential stuffing . Firewall and data loss prevention (DLP) tools that prevent data exfiltration by detecting data staging and enforcing egress rules. See how continuous control validation works in Tenable One. Proactively manage risk prioritization with continuous security control validation. Eliminate noise from theoretical risks that are functionally blocked by existing defenses by integrating compensating security controls into the exposure prioritization process. Access a unified dashboard where assets, vulnerabilities, and exposure risks are consolidated. Filter attack paths to identify which are protected by compensating controls. View types of compensating controls deployed in the environment. Examine attack paths that could be protected with endpoint protection tools. Review security controls associated with specific attack paths, including SIEM and EDR controls. Inspect individual nodes within attack paths to determine which security controls are protecting them. Identify assets monitored by SIEM tools such as Splunk. Verify endpoint protection coverage on assets, including Microsoft Defender installations. Filter attack techniques to focus on specific threats like LSASS Memory techniques, which extract credentials from compromised systems and can be mitigated by endpoint protection tools. Identify attack paths and assets lacking appropriate EDR coverage. Prioritize remediation by examining high-priority attack paths where compensating controls are absent. Collaborate with security control owners to confirm coverage and address gaps in protection for critical assets. Integrate penetration testing data into Tenable One Beyond direct check plugins and continuous control validation, security teams can also integrate penetration testing results into Tenable One that simulate real-world attacks against your cyber defenses. This is another way to validate which exposures are truly exploitable and contextualizes them against your broader attack surface. The Tenable One Open Connector makes it easy to ingest the latest pentest results and layer them with real-time exposure insights to turn your findings into active, continuous defenses. Integrating pentest data into an exposure management program adds critical context to help you understand toxic risk combinations and enrich your understanding of high-severity weaknesses that threaten your most critical business assets. Context is essential in exposure management In the AI era, your security team can’t waste precious time on the wrong issues. With exposure management, context is essential to pinpoint the most critical risks to your organization. Security control validation, coupled with asset criticality, threat activity, entitlement privileges, and attack pathways, give your security team the advantage it needs to stay ahead of threat actors. Learn more about Tenable One , the exposure management platform for the modern attack surface.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (14f3eeecfabfcb249c5f6ec2a20824355ac313ab18c677334076ca9501607ec8) At install time, setup.py invokes install_sitecustomize(), which copies src/temp_development_package_test/setup/sitecustomize.py into Python's purelib site-packages directory as sitecustomize.py (setup.py:34 destination = site_packages / "sitecustomize.py"; setup.py:36 shutil.copy2(source, destination)). Python auto-imports sitecustomize on every interpreter startup, so this places an interpreter-wide hook outside the package's own namespace that fires for every subsequent Python process on the host — a classic persistence mechanism. The hook payload file is not actually shipped in this 0.2 sdist, so the install would currently raise FileNotFoundError, but the install-time mechanism and intent to write a global hook are unambiguous. The package metadata corroborates a throwaway / probe release: name, author, and summary are all the literal placeholder 'temp_development_package_test'; setup.py imports base64 but never uses it; cli.py imports from an unrelated, undeclared module 'pg_agent.orchestration.coordinator'. The combination — placeholder identity plus install-time write of a global interpreter hook — is not a legitimate package shape. ## Source: kam193 (5cdc1d94dd0cfb62a4a0267ae52bf1a72dfa31a6854196b4bb220759b7c6e878) Starting with version 0.4, package installs a sitecustomize.py that executes during Python engine initialization. The embeded code uses mshta to download malicious code, as in other packages from the campaign. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-easyaillm Reasons (based on the campaign): - Downloads and executes a remote executable. - obfuscation - malware - tool:mshta

The npm package 'field-plus' versions 99.99.1 and 99.99.2 contain malicious code that executes during installation. The package.json file includes preinstall and postinstall scripts that silently send identifying information such as username, hostname, current directory, and timestamp to a hardcoded IP address. The package lacks any legitimate functionality and is used as a dependency-confusion or namespace-squatting probe. Installation of this package can lead to full system compromise, requiring immediate secret and key rotation and removal of the package.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (29345b97ddc8c5fe985d1a69d53db15e4126052929267a584b463e94f43b0bc3) tailwind-typography-plus@2.1.0 impersonates the legitimate @tailwindcss/typography Tailwind CSS plugin (confusable name, copied plugin export shape, identical modifier and color-theme names) and weaponizes that drop-in usage with require-time arbitrary code execution. The package main src/index.js calls initScaleEngine() at top level, which runs src/responsive-scale.js. responsive-scale.js loads data/font-metrics.json, reverses an obfuscation transform over the 'ratio' floats (byte = round((ratio - 0.10) / 1.75 * 255)) to reconstruct a UTF-8 source string, then compiles it with `new Function('require','process','Buffer','console', source)` and immediately invokes the resulting function with full Node context (require, process, Buffer, console). Whatever bytes the maintainer encodes into font-metrics.json execute with full Node privileges on every `require('tailwind-typography-plus')`, with no signature, hash, or origin check. Separately, src/styles.js contains a top-level IIFE that on require creates os.tmpdir()/.tailwind-color-space-v2, evades CI environments via `!process.env.CI &&!process.env.TAILWIND_DISABLE_TELEMETRY`, and writes probe-<pid>.json containing arch, platform, execPath, and timestamp. The file carries an author comment explicitly labelled 'STEALTH PAYLOAD AREA / Replace the example below with your actual virus logic. / This executes once on first build after npm install.' — the package documents itself as malware scaffolding. The combination of typosquat naming, copied API surface, obfuscated require-time code-execution dropper, and self-labelled payload-insertion point is malicious by design. ## Source: ghsa-malware (c7c8d8dc7e81d4a27f46d92be719778dbd259d92a62e77e19c7242335c2d2d73) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Ghidra before 12.1 contains a path traversal vulnerability in SameDirDebugInfoProvider that fails to validate filenames from ELF binary .gnu_debuglink sections before constructing file paths. Attackers can craft malicious ELF binaries with traversal sequences to probe filesystem existence and leak CRC32 hashes of arbitrary files during automatic DWARF analysis.

A Server-Side Request Forgery (SSRF) vulnerability in the custom process creation feature of linqi allows an authenticated attacker to probe internal network components. By crafting a specific process containing an HTTP Request component, an attacker can force the server to send arbitrary HTTP requests. By observing the varying application responses (Success, Failed, or 504 Gateway Time-out), the attacker can determine the status of internal ports, leading to internal network reconnaissance.

CVE-2026-7762 is a critical heap-based buffer overflow vulnerability in the Morse Micro HaLowLink 2 dot11ah.ko kernel driver affecting versions prior to 2.11.13. An unauthenticated attacker within radio range can exploit this by sending a crafted 802.11ah beacon or probe response frame with a malformed S1G Capabilities Information Element, causing a kernel panic or potentially remote code execution. The vulnerability arises because the driver copies up to 255 bytes into a 15-byte buffer without proper length validation. Exploitation requires no authentication or user interaction and can occur during normal scanning.

An out-of-bounds read vulnerability in the morse.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.12 allows an unauthenticated attacker within radio range to disclose a small amount of kernel heap memory or cause a Denial of Service (kernel oops/panic) via a crafted 802.11ah beacon or probe response frame containing a malformed Vendor Information Element. The function morse_vendor_find_vendor_ie() does not validate the IE length against the expected structure size before its result is passed to morse_vendor_rx_caps_ops_ie() and morse_vendor_fill_sta_vendor_info(), which read at fixed offsets into the IE data. Because the length check only requires the IE to be longer than 3 bytes, an attacker can supply an undersized IE, causing a heap out-of-bounds read of up to 9 bytes. No authentication, association, or user interaction is required.

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.

In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the Java TLS ioctl probe reads user-controlled ioctl pointers with bpf_probe_read instead of bpf_probe_read_user. An instrumented local process can therefore point OBI at kernel memory and cause that memory to be copied into telemetry. This issue has been patched in version 0.9.0.

OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. This issue has been patched in version 0.9.0.

This update for hplip fixes the following issues: Changes in hplip: - Update to HPLIP 3.26.4 * CVE-2026-8631: Fixed privileges escalation and/or arbitrary code execution via an integer overflow in the hpcups processing path (bsc#1266023) * CVE-2026-8632: Fixed privileges escalation and/or arbitrary code execution via operating system command injection (bsc#1266024) - Add support for the following new printers: * HP LaserJet Pro MFP 3106sdw * HP LaserJet Pro MFP 3105sdw * HP Envy 6500e series * HP Envy 6500 series * HP OfficeJet Pro 9730 Series * HP OfficeJet Pro 9730e Series * HP OfficeJet Pro 9720 Series * HP OfficeJet Pro 9720e Series * HP OfficeJet Pro 8130e All-in-One series * HP OfficeJet Pro 8130 All-in-One series * HP OfficeJet 8130e All-in-One series * HP OfficeJet 8130 All-in-One series * HP OfficeJet Pro 8120e All-in-One series * HP OfficeJet Pro 8120 All-in-One series * HP OfficeJet 8120e All-in-One series * HP OfficeJet 8120 All-in-One series * HP DeskJet Ink Advantage ultra 5800 All-in-One Printer series * HP DeskJet Ink Advantage ultra 5100 All-in-One Printer series * HP DeskJet 4300e All-in-One Printer series * HP DeskJet Ink Advantage 4300 All-in-One Printer series * HP DeskJet 4300 All-in-One Printer series * HP DeskJet 2900e All-in-One Printer series * HP DeskJet Ink Advantage 2900 All-in-One Printer series * HP DeskJet 2900 All-in-One Printer series - Update to HPLIP 3.25.8 - Added support for the following new Printers: * HP LaserJet Enterprise Flow MFP 8601z * HP LaserJet Enterprise 5501 * HP LaserJet Enterprise MFP 5601dn * HP LaserJet Enterprise 6500dn * HP LaserJet Enterprise 5501n * HP LaserJet Enterprise MFP 5601 * HP LaserJet Enterprise 6500 * HP LaserJet Enterprise 5502dn * HP LaserJet Enterprise MFP 5602dn * HP LaserJet Enterprise 6500n * HP LaserJet Enterprise 5502 * HP LaserJet Enterprise MFP 5602f * HP LaserJet Enterprise 6501dn * HP LaserJet Enterprise X50452dn * HP LaserJet Enterprise Flow MFP 5602zfw * HP LaserJet Enterprise 6501 * HP LaserJet Enterprise X50452 * HP LaserJet Enterprise MFP 5602 * HP LaserJet Enterprise X60257dn * HP LaserJet Enterprise MFP X53052dn * HP LaserJet Enterprise Flow MFP X530 * HP LaserJet Enterprise X60257 * HP LaserJet Enterprise MFP X53052 * HP LaserJet Enterprise X60357dn * HP LaserJet Enterprise X60357 * HP LaserJet Enterprise MFP 6600dn * HP LaserJet Enterprise Flow MFP 6600zfw * HP LaserJet Enterprise MFP 6600 * HP LaserJet Enterprise Flow MFP 6600zfsw * HP LaserJet Enterprise MFP X62757dn * HP LaserJet Enterprise Flow MFP X62757zs * HP LaserJet Enterprise MFP X62757 * DEX D50452dn * DEX MFP D53052dn - Fix handling of readfp() and read_filke() for ConfigParser objects, avoiding confusing error messages (lp#2139771) - Fix compiler warnings on SLE15 - Fix "Found No Section" error with python (lp#2095776) - Fix PPD lookup by moving PPDs from manufacturer-PPDs/hplip-fax to manufacturer-PPDs/hplip/fax etc (boo#1257529) - Move more utilities from hplip-utils to hplip-base. * hplip-base now contains all utilities that are not totally useless and can run without the Qt GUI. - Update fix for support of new GPG key, as the key has now been uploaded to GPG keyservers (lp#2120738) - This fixes CVE-2025-43023 (bsc#1266031) - Drop dependency on cups-ppdc. It isn't necessary, as PPD generation on target system is done by cups-driverd. - The old and outdated 'hpijs' driver support is finally dropped (the 'hpcups' driver is the default driver since 2009) so that there is no need for foomatic-filters (boo#1250481) - Continue refactoring: * move GUI tools to "hplip-utils" subpackage * convert "hplip" into an empty metapackage that pulls in hplip-utils and all drivers / PPDs (except hpijs PPDs). - Refactor package structure: * hplip: full set of utilities. Pulls in almost all subpackages to deliver the "traditional" hplip experience * hplip-base: small set of basic utilities that can be run without GUI. Includes hp-probe and hp-plugin * hplip-cups: minimal package for printing, without PPDs or setup helpers * hplip-sane: scanning support (unchanged) * hplip-driver-hpcups: hpcups.drv for generating hpcups PPDs on the fly (requires ppdc). The functionality of this package is similar to the old (misnamed) "hplip-hpijs" package. * hplip-driver-hpijs: hpijs.drv for generating PPDs for the deprecated hpijs / foomatic_rip filter. Note that this functionality was not part of the late hplip-hpijs package, because upstream hasn't ship foomatic PPDs since hplip 3.17.11. * hplip-ppds-{hpcups,hpps,postscript,hpijs,fax,plugin}: static PPD files for different printer types. hplip-ppds-hpcups is an alternative to hplip-driver-hpcups. * libhplip0: shared library package, used by hplip-cups and hplip-sane * hplip-common: configuration files and directories

In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.

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: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.

A vulnerability in the Linux kernel tracepoint subsystem was resolved, where failure to properly clean up after a failed probe installation could leave persistent side effects. Specifically, if func_add() fails during a tracepoint transition, the corresponding unregistration function is not called, causing resource leaks such as stuck reference counts and ongoing syscall trace overhead. This issue affects certain Linux Azure kernel versions and has been fixed in later releases.

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-battery: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.