The researcher who found it says the vulnerability could have been chained with a prompt injection to exfiltrate data.
The post Anthropic Silently Patches Claude Code Sandbox Bypass appeared first on SecurityWeek.
Mozilla has published release notes for Firefox browser version 151.0, and this update includes several genuinely meaningful privacy and security improvements.
Three changes stand out in particular:
Note that Mozilla says several Firefox 151 features are “part of a progressive roll out,” meaning they will appear for some users first and be expanded over time. So, you may not see all of them immediately.
One of the more visible additions is a new “end private session” control in Private Browsing Mode. Instead of closing every private window to clear your traces, you now get a dedicated fire‑icon button next to the address bar that wipes the current private session’s data and immediately starts a fresh one.
Under the hood, this clears the usual private browsing artifacts for that session, including history, cookies, cached files, and other site data that would normally disappear only when the last private window closes.
For people who routinely mix normal and private windows, this is safer and less error‑prone than hunting down every private tab before you walk away from the machine.
Firefox 151 also tightens its defenses against browser fingerprinting in the default “Standard” Enhanced Tracking Protection (ETP) mode. Mozilla says Firefox now limits the amount of device and browser information exposed to websites in a way that reduces the number of uniquely identifiable users by about 14% overall, and by roughly 49% on macOS.
This makes it harder for trackers to pick you out of the crowd, especially on platforms with fewer users to begin with (like certain macOS configurations). This reduces the privacy risk surface by default, which makes it harder for phishing and landing pages that redirect visitors to “categorize” you.
Another important change is Firefox’s “local network access restrictions,” which are now rolling out to all users, not just those who turned Enhanced Tracking Protection to Strict.
This means that when a website wants to communicate with devices on your local network, or with apps and services running on your machine, Firefox now asks for permission first. Chrome and Edge have been rolling out similar permission prompts.
Firefox 151 also quietly fixes several security vulnerabilities.
The most notable example is CVE‑2026‑8953, a sandbox escape due to a use‑after‑free in the Disability Access APIs component. While there are currently no reports of in‑the‑wild exploitation for this specific bug at the time of writing, this is the kind of bug cybercriminals love.
A use-after-free (UAF) is a software memory vulnerability where a program attempts to access a memory location after it has been freed. If the program fails to clear the pointer to that freed memory, attackers can manipulate the error to crash the system or execute arbitrary code. A memory corruption leading to a sandbox escape is exactly the kind of link attackers want to complete a browser exploit chain.
If you’re running Firefox in a home or small‑office environment, we recommend updating to Firefox 151 as soon as possible to get the fingerprinting protections, local network access prompts, and security patches.
To update Firefox:
Once your Firefox browser has been updated, it will show a green checkmark along with the message: “Firefox is up to date.”
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
A compromised maintainer account was used to publish malicious package versions across the @antv namespace.
The post Over 320 NPM Packages Hit by Fresh Mini Shai-Hulud Supply Chain Attack appeared first on SecurityWeek.
As enterprises rush AI projects into production, security teams are increasingly being forced into reactive mode.
The post Caught Off Guard: Securing AI After It Hits Production appeared first on SecurityWeek.
SecurityWeek spoke with several ICS security experts and companies about their most memorable experiences in the field.
The post Real-World ICS Security Tales From the Trenches appeared first on SecurityWeek.
Don't miss this virtual event as we explore how to cut through alert fatigue, leverage AI and unified platforms to accelerate investigations, and apply actionable threat intelligence.
The post Virtual Event Today: Threat Detection & Incident Response Summit appeared first on SecurityWeek.
The TeamPCP hacking group accessed the repositories after a GitHub employee installed a poisoned VS Code extension.
The post GitHub Confirms Hack Impacting 3,800 Internal Repositories appeared first on SecurityWeek.
ExifTool is a widely adopted utility for reading and writing metadata in image, PDF, audio, and video files. It is available both as a standalone command-line application and as a library that can be embedded in other software. In this article, we break down CVE-2026-3102, an ExifTool vulnerability discovered by Kaspersky’s Global Research and Analysis Team (GReAT) in February 2026 and patched by the developers within the same month. Affecting macOS systems with ExifTool version 13.49 and earlier, this flaw could let an attacker run arbitrary commands by hiding instructions inside an image file’s metadata.
This investigation originated from revisiting an n-day vulnerability I first examined years ago: CVE-2021-22204. That flaw exploited weak regex-based sanitization before feeding user input into an eval sink. By auditing adjacent input validation routines across ExifTool codebase for similar oversights, I discovered CVE-2026-3102. Successful exploitation of CVE-2026-3102 enables an attacker to execute arbitrary shell commands with the privileges of the user invoking ExifTool, potentially leading to full system compromise.
Exploiting CVE-2026-3102 requires the -n (also known as -printConv) flag and outputs machine-readable data without additional processing.
Taint analysis (aka tainted data analysis) allows for the detection of “dirty” data that reaches dangerous locations without validation. In this context, a “sink” is a point or function in a program where data or a parameter marked as “tainted” or originating from an untrusted source (e.g., user input) can affect the program’s behavior. In ExifTool, these functions are eval and system, both of which are capable of executing system commands. While CVE-2021-22204 exploited an eval function as a sink, this vulnerability (CVE-2026-3102) targets the system function. Knowing the vulnerable sink, we needed to trace how user-controlled data reaches it. Below, we break down the details.
The screenshot above shows where the system() sink resides within the SetMacOSTags function. Tracing backward from system(), we identified the $cmd variable as the source of the executed command. This variable is assembled from three inputs: $file (properly sanitized), $setTags (processed iteratively), and $val (user-controlled and, crucially, left unsanitized in the vulnerable branch).
In ExifTool, a tag is a named metadata field. When parsing an image, the utility extracts date and time values from standard EXIF records or macOS filesystem attributes. To handle file creation dates on macOS, ExifTool relies on the Spotlight system attribute MDItemFSCreationDate. Within the program code, this attribute maps to the internal alias $FileCreateDate. These two identifiers govern how the file creation date is stored and applied.
This creates a critical link to the vulnerability: when parsing an image, ExifTool iterates through the discovered tags. The current tag’s name is assigned to the $tag variable, while its text content (e.g., a date string) is assigned to $val. The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate. At this point, the tag’s content flows into $val and is passed to the SetMacOSTags function. As shown in the screenshot below, the filename parameter is properly escaped, but the date value ($val) is not. Because the date is extracted directly from file metadata, an attacker can inject quotes into this field. This breaks the command structure and allows the payload to execute via the system() sink.
The following screenshots show some of the tags that can be modified. With the vulnerable parameter identified, the next challenge was delivery: how to place our payload into FileCreateDate without triggering early validation? We found the answer in the official documentation.
Let’s refer to the documentation to understand how ExifTool handles tag operations and identify a legitimate feature that can be repurposed for exploitation. Specifically, we need to find a way to deliver our payload into the vulnerable FileCreateDate parameter. When looking for macOS-related tags as well as FileCreateDate, we can find the following information:
Login
-geotag, -csv= or -json=-tagsFromFile feature is used.(You can find the useful info on tag operations above and how it relates under the hood in ExifTool in the dedicated section of the documentation and on the ExifTool description page.)
To trigger the vulnerability, we need to copy a string (date format: MM/DD/YYYY) using the -tagsFromFile feature, as this operation invokes the SetMacOSTags function where the unsanitized $val parameter reaches the system() sink.
Why copy instead of writing directly? Because the vulnerable code path (SetMacOSTags) is only triggered when metadata is copied into FileCreateDate — not when it is written directly. By using -tagsFromFile, we can prepare a “source” tag (e.g., DateTimeOriginal) that accepts arbitrary values and copy that value into FileCreateDate, thereby invoking the vulnerable function with our controlled input.
Furthermore, we want to introduce single quotes (since they are not being escaped in $val). For starters, we can look for date-time tag and copy via -tagsFromFile by searching the EXIF tag table. Direct assignment to FileCreateDate is heavily validated, so we looked for a source tag that accepts raw values and can be copied into the target field. The following snippet shows the beginning of said table.
When doing the analysis, I made use of DateTimeOriginal though I believe you can also use CreateDate which is 0x9004 (see the following screenshot). Initial attempts to inject malformed dates failed: ExifTool’s built-in filter rejected the input. To bypass this, we examined how the tool handles raw metadata.
To confirm that the PrintConvInv filter rejects invalid dates when written directly, I ran the following command, where evil_benign.jpg is a normal JPG with an invalid date time format. We are greeted with the error message: Invalid date/time. This requires the time as well. The next screenshot confirms that direct exploitation fails: ExifTool’s date validation detects the malformed input and rejects the change, activating the internal PrintConvInv filter.
That said, it is possible to ignore the formatting and use the -n flag which accepts raw values instead of human-readable value. The -n flag skips the PrintConvInv conversion step, which is exactly where input sanitization occurs. This confirmed we could park unsanitized data in a source tag. The final step was to trigger the vulnerable code path by copying that data into FileCreateDate. This means we should now be able to modify the DateTimeOriginal tag with the invalid date time format with an -n flag. Examining the EXIF metadata tag, we can confirm that we can store a raw value without a proper human readable format that ExifTool accepts:
To inject commands, we have to revisit the single quote injection into this datetime related tag.
The following screenshot shows that we have successfully set the datetime metadata with the single quote. With the payload safely stored in a source tag, the next step was to copy it into FileCreateDate, triggering the vulnerable system() call.
The next step now is to copy the datetime tag to a file which invokes SetMacOSTags. According to the documentation, this is how we can copy the data from the SRC tag to the FileCreateDate tag as seen in the SetMacOSTags with the -tagsFromFile feature.
exiftool [_OPTIONS_] -tagsFromFile _SRCFILE_ [-[_DSTTAG_<]_SRCTAG_...] _FILE_...
Therefore, we can craft our final command:
cp evil_benign.jpg pwn.jpg; ../../exiftool -n -tagsFromFile evil_benign.jpg "-FileCreateDate<DateTimeOriginal" pwn.jpg
Here, we confirm that the payload has been executed! Note that when copying tags in MacOS (Darwin), the /usr/bin/setfile command is used. To view the full $cmd value before the injection, I have added the debugging statement to displaying the actual command that is executed within the system function.
Upon injection, we can see that our command gets executed via command substitution. The single quotes that we added helped to make the entire command syntactically valid. The following shows a more detailed labelling and their roles in making this command line injection successful:
Such an image can appear completely benign and easily find its way into a newsroom or any organization that processes photos on macOS using ExifTool. Once processed, an attacker could silently deploy a Trojan for covert data exfiltration, drop additional malware, or use the compromised machine as a foothold to expand the attack within the victim’s network.
After verifying successful exploitation, we examined how the maintainer addressed the flaw in version 13.50. In the vulnerable version of ExifTool, commands were sanitized before being concatenated together. This means that it is possible to concatenate single quotes which led to the exploitation. However, by abstracting the system call into a dedicated wrapper and requiring a list of arguments instead of concatenated string, the fix removes the need for any manual escaping altogether.
1. Replacing string form to argument list form:
#### BEFORE
$cmd = "/usr/bin/setfile -d '${val}' '${f}'";
system $cmd;
#### AFTER
system('/usr/bin/setfile', '-d', $val, $file);2. Create new System() wrapper. In version 13.49, the output is piped to /dev/null . To maintain that logic, the wrapper would temporarily redirect STDOUT/STDERR to /dev/null and restore them after the call.
# Call system command, redirecting all I/O to /dev/null
# Inputs: system arguments
# Returns: system return code
sub System
{
open(my $oldout, ">&STDOUT");
open(my $olderr, ">&STDERR");
open(STDOUT, '>', '/dev/null');
open(STDERR, '>', '/dev/null');
my $result = system(@_);
open(STDOUT, ">&", $oldout);
open(STDERR, ">&", $olderr);
return $result;
}
It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.
ExifTool, like any software, may contain additional vulnerabilities of this class. To harden defenses, I recommend using Kaspersky Open Source Software Threats Data Feed for continuous monitoring of open-source components in your software supply chain, and Kaspersky for macOS as comprehensive endpoint protection. Additionally, isolate processing of untrusted files on dedicated machines or virtual environments with strictly limited network and storage access. If you work with freelancers, contractors, or allow BYOD, enforce a policy that only devices with an active macOS security solution can access your corporate network.
CVE-2026-3102 highlights the risks of inconsistent input sanitization in tools that bridge high-level metadata parsing with platform-specific utilities. While exploitation requires explicit flag usage (-n) and is restricted to macOS, the vulnerability underscores the danger of manual escaping routines in evolving codebases. The transition to list-form system execution provides a robust, architecture-level fix that eliminates shell interpretation risks entirely. This case reinforces a core security principle: replacing fragile string concatenation with secure, list-based API calls remains the most reliable mitigation against command injection.
Verizon’s 2026 DBIR finds vulnerability exploitation has overtaken credential abuse as the leading breach vector, as AI accelerates attacks, patching delays worsen, and ransomware and third-party compromises continue to surge.
The post Verizon DBIR 2026: Vulnerability Exploitation Overtakes Credential Theft as Top Breach Vector appeared first on SecurityWeek.
For years, civil society organizations, workers, journalists, and human rights experts have warned that major technology companies risk enabling grave human rights abuses when they provide cloud computing, AI, and surveillance infrastructure to governments implicated in violations of international and humanitarian law. While many companies pay lip service to evaluating customers and contracts for human rights implications (lip service Exhibit A: Palantir!), too often those processes fail to provide any meaningful accountability when their standards are not met or are simply ignored. But recent developments at Microsoft suggest that accountability for failing to uphold the human rights standards that a company itself sets, even if incomplete, is possible.
According to recent reporting, Microsoft’s Israel chief has departed amid an escalating ethical controversy surrounding the company’s business relationships with the Israeli Ministry of Defense. The move follows months of scrutiny, internal dissent, and sustained pressure from inside the organization along with press and civil society, especially after a report by The Guardian revealed that Microsoft technologies were used in systems connected to mass surveillance and military targeting operations in Gaza in ways that appeared to violate Microsoft’s own standards. This did not happen overnight.
In September 2025, Microsoft reportedly suspended certain services after initial investigations raised serious concerns about how its cloud and AI infrastructure may have been used. That alone distinguished Microsoft from many of its peers. Rather than simply dismissing mounting concerns or hiding behind vague claims of neutrality, Microsoft appeared to recognize that providing technology in conflict settings creates real human rights responsibilities. Now, after additional investigation and continued public scrutiny, it appears the company has taken another step, one that should send a strong signal to others that violating Microsoft’s human rights commitments could cost you your job. This is important.
There is still much more Microsoft should do, of course. The company has yet to fully disclose the scope of its findings, explain exactly which services were suspended, or clarify what safeguards remain in place to prevent its technologies from contributing to human rights abuses in the future. We shouldn’t have to infer the connection between this employment action and the company’s investigation.
Just prior to reports that Microsoft had fired its Israel Country General Manager, EFF joined Access Now, Amnesty International, Fight for the Future, and 7amleh in a joint May 7, 2026 letter to Microsoft leadership calling on the company to publicly release the findings of its investigation, suspend business relationships tied to serious human rights abuses, and implement meaningful safeguards to prevent its technologies from contributing to further harm. The letter detailed allegations regarding Microsoft’s reported provision of Azure cloud and AI services to Israeli military and intelligence units involved in surveillance and targeting operations, while also pressing the company to take concrete human rights due diligence measures going forward. Those demands remain urgent, even as Microsoft appears to be taking some of the steps we urged.
But even as we push for more, it is important to recognize when a company takes steps in the right direction. Because this is what it means to put human rights commitments into practice. It means acknowledging that human rights policies are not just branding exercises or transparency reports. It means accepting that companies providing cloud infrastructure and AI services have responsibilities when credible evidence emerges that their technologies may be enabling violations of international law. And it means taking concrete action when those risks become known.
The allegations facing Microsoft are serious. Human rights organizations and investigative reporting have documented claims that Microsoft Azure services were used by Israeli military and intelligence units to process large-scale surveillance data, support AI-assisted targeting systems, and sustain military cloud infrastructure during the war in Gaza. The concerns raised extend beyond ordinary business risk; they implicate potential complicity in violations of international humanitarian and human rights law.
Faced with these allegations, Microsoft could have chosen the path many tech companies take: deny everything, attack critics, suppress worker dissent, and continue business as usual. Instead, the company appears to have begun responding to the evidence.
Technology companies are not powerless bystanders. Cloud providers and AI companies make choices every day about who gets access to their infrastructure, under what conditions, and with what oversight. When companies claim to uphold human rights principles, those commitments should have operational consequences. Too many companies, in both international and domestic policing contexts, provide technology to institutions that violate people’s human rights and civil liberties, then fall back on the claim that they are merely providing a service that their customers can use how they see fit. This is an ethical failing that falls short of most companies’ publicly expressed commitments. Microsoft’s recent actions suggest that sustained public pressure, worker organizing, investigative journalism, and civil society advocacy can force even the world’s largest technology companies to respond.
Google and Amazon should especially see this as a clear example to follow. Both companies also provide services to the Israeli Ministry of Defense and have faced years of criticism over those contracts and services, including from EFF. Yet neither has demonstrated the level of responsiveness or accountability that Microsoft has shown. If Microsoft can suspend services, investigate allegations, and make leadership changes amid mounting evidence and ethical concerns, then other cloud giants can no longer pretend that meaningful action is impossible.
The technology industry has spent years insisting that ethics and human rights matter. The real test has always been whether those principles survive when profits, government contracts, and geopolitical pressure are on the line. Microsoft’s recent steps are not the end of that story, but they may mark the beginning of what real accountability can look like.
We’re looking at you, Amazon and Google. If Microsoft can do it, why can’t you?
