Microsoft has remediated three critical cloud-service vulnerabilities that demonstrate how an ordinary image upload can become a path to full remote code execution on production infrastructure. Two of the flaws affected Bing Images, where specially crafted image content could reach a dangerous server-side conversion path and execute commands with SYSTEM-level privileges on Windows workers; the third affected the Microsoft Devices Pricing Program through an unrestricted file-upload issue.
The most important point for Bing users is reassuring: these were server-side defects in Microsoft-hosted services, and the fixes are already in place. No Windows Update, browser update, password reset, or change in normal Bing use is required for consumers.
For administrators and developers, however, the disclosure deserves close attention. The underlying pattern is neither unique to Bing nor especially new: rich “image” formats such as SVG can traverse parsing, conversion, metadata, and rendering components that were never designed to be exposed loosely to hostile input. When those components retain legacy features that can invoke external programs or interpret special syntax, an image-processing workflow can become an unauthenticated remote code execution vulnerability.
The technical disclosure published on July 23, 2026 expands on fixes that Microsoft had already associated with March 2026 vulnerability advisories. That timing matters. This is not evidence of a newly unpatched Bing Images zero-day on July 24; it is a detailed post-remediation account of flaws that were responsibly reported and addressed before exploit mechanics were released.
All three vulnerabilities received a CVSS 3.1 score of 9.8 out of 10, placing them in the Critical category. The scoring reflects a particularly serious combination: attacks could be performed remotely, required no prior authentication, needed no user interaction, and could potentially compromise confidentiality, integrity, and availability.
The three tracked issues are:
That distinction is worth preserving. A direct upload path and a backend URL-fetch path may ultimately reach the same vulnerable component, but each is an independent exposure route with different defensive controls. One is primarily an upload-validation and file-processing problem. The other combines server-side request forgery (SSRF) concerns with unsafe processing of the content retrieved by the backend.
From a user perspective, that sounds straightforward. Upload a picture, receive matching images. But a modern visual-search service must do considerably more in the background:
An attacker does not need a conventional executable file if a trusted backend component can be induced to treat part of a document-like image format as an instruction. The service may believe it is handling a graphic. The underlying tool may be handling XML, URL references, conversion delegates, pseudo-protocols, or compatibility functionality inherited from decades of image-processing software.
That gap between what the application thinks it is accepting and what the helper component actually parses is where this class of vulnerability lives.
That flexibility makes SVG useful in trusted web and design workflows. It also makes SVG substantially more complicated to handle safely in public-facing processing pipelines.
A secure service cannot treat an SVG as equivalent to a simple raster image simply because users see both as pictures. SVG support can invoke XML parsing, reference resolution, rendering engines, and conversion features that have a much broader attack surface than decoding a conventional bitmap.
The reported Bing Images flaws appear to have emerged when crafted SVG content was delivered to a conversion system that still allowed a dangerous delegate-style path. The application’s front end did not need to explicitly call a shell. It was enough that one downstream image-processing component could interpret attacker-controlled content in a way that eventually reached shell-backed behavior.
That is precisely why security teams must evaluate the full processing chain, not merely check whether an upload endpoint blocks
The critical characteristics were severe:
This is where the SSRF aspect becomes important.
A basic SSRF finding often means a backend server can be coaxed into making a request it would not otherwise make. That can be dangerous by itself, especially if the server can reach internal systems, cloud metadata endpoints, or management interfaces inaccessible to the public internet.
In this case, the backend fetch was not the final impact. It was the delivery vehicle. The more serious issue was what happened after Bing fetched the content: the file was sent into the image-processing stack, where crafted SVG input could reach the unsafe execution path.
That chain is a valuable reminder for defenders. A server-side fetch that appears low impact can become critical when the fetched response is automatically handed to another complex parser.
That is often reasonable. It is also sometimes wrong.
A server error caused by unusual content may reveal that the input is reaching a deeper processing layer than expected. When response behavior differs across file types, encodings, redirects, or content structures, it can expose the outline of the backend pipeline.
For developers, this does not mean every 500 error is evidence of remote code execution. It does mean that public endpoints handling untrusted files should be instrumented and reviewed with a threat-modeling mindset. Errors around parsing, conversion, preview generation, thumbnailing, and metadata extraction deserve more attention than generic application faults.
That combination reveals two things.
First, the affected processing tier appears to have been heterogeneous. Large cloud services routinely use multiple operating systems, pools, containers, job schedulers, and worker configurations. Security validation cannot assume that one observed host represents every backend environment.
Second, the privilege level was excessive for a service that processes untrusted image content. On Windows, NT AUTHORITY\SYSTEM is the operating system’s most powerful local security context. A process running as SYSTEM can access protected files, services, registry locations, and system-level resources far beyond the reach of an ordinary user account.
On Linux, UID 0 is similarly powerful. Even when services are isolated by containers, network boundaries, or cloud controls, code execution as root within a worker can dramatically increase the consequences of a compromise.
It is important not to overstate what the disclosure proves. Remote code execution on a processing worker does not automatically mean access to every Microsoft service, all customer data, or the entire Azure environment. Mature cloud platforms employ layered segmentation, identity controls, monitoring, and containment systems precisely to limit blast radius.
But SYSTEM-level remote code execution on production infrastructure is still an exceptionally serious foothold. It gives an attacker code execution inside a trusted service boundary, creates potential for reconnaissance, credential theft, lateral movement, data exposure, and service disruption, and requires a fast, carefully engineered response.
A decade later, the same strategic lesson applies: image conversion software often contains more capability than application developers realize.
A converter may support:
The security failure is not simply “using ImageMagick” or any other well-known media library. Mature conversion software can be deployed securely. The failure comes from exposing a broad, feature-rich configuration to adversarial files without strict policy controls, sandboxing, and network restrictions.
The phrase that best summarizes the problem is simple: attackers treat image helpers as parsers.
A web application may regard image conversion as plumbing: upload a file, resize it, save a thumbnail, continue the request. An attacker sees a parser capable of processing rich formats, resolving references, reading strange metadata, and possibly invoking external behavior.
The public technical detail available for this flaw is more limited than for the Bing Images vulnerabilities. That restraint is appropriate, because detailed reproduction information can remain useful to attackers even after a fix has rolled out.
Still, the classification alone provides an important defensive lesson. An unrestricted upload vulnerability is not just a matter of allowing an unwanted extension. It can occur when a system:
This same multi-stage risk exists in Bing Images. A file can be accepted safely by one layer, then become dangerous when a later helper parses it in a different way.
That claim is noteworthy because the research was not based on a trivial, known pattern match. The process reportedly involved observing a blind backend fetch, interpreting inconsistent server responses, eliminating alternate hypotheses, identifying a likely conversion stack, mapping which input paths were enabled, and validating execution safely through controlled callbacks.
In other words, the reported achievement was not simply generating a payload. It was sustaining a multi-step investigation through ambiguity and dead ends.
The more realistic shift is one of speed and persistence.
An automated offensive system can test large numbers of variations, keep detailed records of results, revisit weak signals, and continue methodically where a human researcher might stop because a single issue appears low severity. That is particularly relevant to parser and workflow vulnerabilities, where no individual clue is conclusive.
Defensive teams should assume that attackers will increasingly use automation to:
The lasting importance of this story is not whether a machine or a person took the final investigative step. It is that a familiar flaw class—unsafe interpretation of untrusted file content—persisted inside a modern, globally exposed cloud workflow.
Automation may have accelerated the discovery. The underlying engineering lesson remains longstanding and universal.
The affected systems were Microsoft-hosted services, and the remediation was deployed server-side. These were not vulnerabilities in the Bing app, Microsoft Edge, Windows 11, Windows Server installations owned by customers, or user accounts.
That means users do not need to:
The highest-value changes are architectural. Blocking one file extension is useful, but it is not enough if a conversion library identifies content by magic bytes, follows embedded references, or supports a broader set of formats than the application team intends.
For many applications, that means limiting uploads to raster formats such as:
Do not rely only on file extensions. Validate the actual content, normalize it safely, and reject ambiguous or polyglot files.
Key controls include:
A safer conversion architecture includes:
A conversion worker processing untrusted files rarely needs unrestricted internet access. Apply egress rules so it cannot freely reach:
At a minimum:
Useful indicators include:
Yet each feature can activate powerful parsing and conversion behavior on the backend.
The fixes to Bing Images remove the immediate risk to users of Microsoft’s service. The broader warning remains: untrusted content is active input, even when it looks like a picture.
Organizations that treat image processing as a privileged, networked, feature-rich parser environment—and secure it accordingly—will be far better prepared for the next vulnerability that begins with nothing more suspicious than an uploaded image.
The most important point for Bing users is reassuring: these were server-side defects in Microsoft-hosted services, and the fixes are already in place. No Windows Update, browser update, password reset, or change in normal Bing use is required for consumers.
For administrators and developers, however, the disclosure deserves close attention. The underlying pattern is neither unique to Bing nor especially new: rich “image” formats such as SVG can traverse parsing, conversion, metadata, and rendering components that were never designed to be exposed loosely to hostile input. When those components retain legacy features that can invoke external programs or interpret special syntax, an image-processing workflow can become an unauthenticated remote code execution vulnerability.
The technical disclosure published on July 23, 2026 expands on fixes that Microsoft had already associated with March 2026 vulnerability advisories. That timing matters. This is not evidence of a newly unpatched Bing Images zero-day on July 24; it is a detailed post-remediation account of flaws that were responsibly reported and addressed before exploit mechanics were released.
Overview: Three Critical Cloud-Service Vulnerabilities
All three vulnerabilities received a CVSS 3.1 score of 9.8 out of 10, placing them in the Critical category. The scoring reflects a particularly serious combination: attacks could be performed remotely, required no prior authentication, needed no user interaction, and could potentially compromise confidentiality, integrity, and availability.The three tracked issues are:
- CVE-2026-32194 — A command-injection vulnerability in the Bing Images processing pipeline, reachable through a public image-upload workflow.
- CVE-2026-32191 — A related OS command-injection vulnerability in Bing Images, reached through a server-side image-fetching path associated with reverse-image-search processing.
- CVE-2026-21536 — A remote code execution vulnerability in the Microsoft Devices Pricing Program, classified as an unrestricted upload of a file with a dangerous type.
That distinction is worth preserving. A direct upload path and a backend URL-fetch path may ultimately reach the same vulnerable component, but each is an independent exposure route with different defensive controls. One is primarily an upload-validation and file-processing problem. The other combines server-side request forgery (SSRF) concerns with unsafe processing of the content retrieved by the backend.
The Bing Images Attack Surface Was Bigger Than It Looked
Bing’s reverse-image-search functionality is expected to handle untrusted image data. That is its core purpose: a person can submit an image or provide an image URL, after which the service analyzes visual features and returns related search results.From a user perspective, that sounds straightforward. Upload a picture, receive matching images. But a modern visual-search service must do considerably more in the background:
- Receive or retrieve image data.
- Identify the actual file format.
- Decode and normalize the content.
- Resize or rasterize it for downstream analysis.
- Extract visual features or metadata.
- Route the processed output through search and ranking systems.
An attacker does not need a conventional executable file if a trusted backend component can be induced to treat part of a document-like image format as an instruction. The service may believe it is handling a graphic. The underlying tool may be handling XML, URL references, conversion delegates, pseudo-protocols, or compatibility functionality inherited from decades of image-processing software.
That gap between what the application thinks it is accepting and what the helper component actually parses is where this class of vulnerability lives.
Why SVG Is Not “Just an Image”
The Bing proof-of-concept centered on SVG, or Scalable Vector Graphics. SVG is an image format, but unlike JPEG or PNG, it is text-based XML. It can define shapes, text, filters, embedded resources, and links to other content.That flexibility makes SVG useful in trusted web and design workflows. It also makes SVG substantially more complicated to handle safely in public-facing processing pipelines.
A secure service cannot treat an SVG as equivalent to a simple raster image simply because users see both as pictures. SVG support can invoke XML parsing, reference resolution, rendering engines, and conversion features that have a much broader attack surface than decoding a conventional bitmap.
The reported Bing Images flaws appear to have emerged when crafted SVG content was delivered to a conversion system that still allowed a dangerous delegate-style path. The application’s front end did not need to explicitly call a shell. It was enough that one downstream image-processing component could interpret attacker-controlled content in a way that eventually reached shell-backed behavior.
That is precisely why security teams must evaluate the full processing chain, not merely check whether an upload endpoint blocks
.exe files.Two Routes Into the Same High-Risk Processing Tier
The technical analysis describes two Bing Images routes that converged on a vulnerable conversion boundary.Direct Image Upload Through Search by Image
CVE-2026-32194 affected a public image-upload flow. An attacker could submit crafted image content to Bing’s “Search by Image” functionality, and the backend image-processing pipeline could eventually execute attacker-controlled commands.The critical characteristics were severe:
- No account was required.
- No session cookies were required.
- No user interaction was required.
- The vulnerable component was reachable from the public internet.
- The processing occurred on Microsoft production infrastructure.
Server-Side Fetching Through the Crawler Path
CVE-2026-32191 covered a related path in which Bing fetched an attacker-hosted image file itself. The attacker could provide a URL through a reverse-image-search workflow, causing Microsoft infrastructure to retrieve the file before image processing occurred.This is where the SSRF aspect becomes important.
A basic SSRF finding often means a backend server can be coaxed into making a request it would not otherwise make. That can be dangerous by itself, especially if the server can reach internal systems, cloud metadata endpoints, or management interfaces inaccessible to the public internet.
In this case, the backend fetch was not the final impact. It was the delivery vehicle. The more serious issue was what happened after Bing fetched the content: the file was sent into the image-processing stack, where crafted SVG input could reach the unsafe execution path.
That chain is a valuable reminder for defenders. A server-side fetch that appears low impact can become critical when the fetched response is automatically handed to another complex parser.
A “500 Internal Server Error” Can Be a Security Signal
One of the more instructive parts of the research is that the investigation began with inconsistent behavior and HTTP 500 errors. In many real-world environments, odd parsing errors are written off as reliability issues, malformed input, or harmless edge cases.That is often reasonable. It is also sometimes wrong.
A server error caused by unusual content may reveal that the input is reaching a deeper processing layer than expected. When response behavior differs across file types, encodings, redirects, or content structures, it can expose the outline of the backend pipeline.
For developers, this does not mean every 500 error is evidence of remote code execution. It does mean that public endpoints handling untrusted files should be instrumented and reviewed with a threat-modeling mindset. Errors around parsing, conversion, preview generation, thumbnailing, and metadata extraction deserve more attention than generic application faults.
SYSTEM and Root: Why Privilege Context Changes the Severity
The researchers reported successful command execution across multiple production workers and network ranges, rather than on a single anomalous host. Their callbacks reportedly showed both Linux root-level execution and NT AUTHORITY\SYSTEM execution on Windows Server 2022 Datacenter workers.That combination reveals two things.
First, the affected processing tier appears to have been heterogeneous. Large cloud services routinely use multiple operating systems, pools, containers, job schedulers, and worker configurations. Security validation cannot assume that one observed host represents every backend environment.
Second, the privilege level was excessive for a service that processes untrusted image content. On Windows, NT AUTHORITY\SYSTEM is the operating system’s most powerful local security context. A process running as SYSTEM can access protected files, services, registry locations, and system-level resources far beyond the reach of an ordinary user account.
On Linux, UID 0 is similarly powerful. Even when services are isolated by containers, network boundaries, or cloud controls, code execution as root within a worker can dramatically increase the consequences of a compromise.
It is important not to overstate what the disclosure proves. Remote code execution on a processing worker does not automatically mean access to every Microsoft service, all customer data, or the entire Azure environment. Mature cloud platforms employ layered segmentation, identity controls, monitoring, and containment systems precisely to limit blast radius.
But SYSTEM-level remote code execution on production infrastructure is still an exceptionally serious foothold. It gives an attacker code execution inside a trusted service boundary, creates potential for reconnaissance, credential theft, lateral movement, data exposure, and service disruption, and requires a fast, carefully engineered response.
The ImageTragick Lesson Has Not Gone Away
The Bing Images flaws echo the broader history of ImageTragick, the name commonly used for a family of ImageMagick vulnerabilities disclosed in 2016. Those issues demonstrated that image files could exploit unsafe coders, delegates, and file-reference handling to trigger command execution in systems that used ImageMagick to process untrusted files.A decade later, the same strategic lesson applies: image conversion software often contains more capability than application developers realize.
A converter may support:
- Legacy file formats.
- PostScript or vector formats.
- Embedded image references.
- Network protocols.
- Indirect file reads.
- External delegates.
- Filters and helper programs.
- Metadata parsers.
- Text rendering systems.
- Document interpreters.
The security failure is not simply “using ImageMagick” or any other well-known media library. Mature conversion software can be deployed securely. The failure comes from exposing a broad, feature-rich configuration to adversarial files without strict policy controls, sandboxing, and network restrictions.
The phrase that best summarizes the problem is simple: attackers treat image helpers as parsers.
A web application may regard image conversion as plumbing: upload a file, resize it, save a thumbnail, continue the request. An attacker sees a parser capable of processing rich formats, resolving references, reading strange metadata, and possibly invoking external behavior.
Why the Devices Pricing Program Vulnerability Matters Too
The third issue, CVE-2026-21536, affected the Microsoft Devices Pricing Program and was classified as an unrestricted upload of a file with a dangerous type.The public technical detail available for this flaw is more limited than for the Bing Images vulnerabilities. That restraint is appropriate, because detailed reproduction information can remain useful to attackers even after a fix has rolled out.
Still, the classification alone provides an important defensive lesson. An unrestricted upload vulnerability is not just a matter of allowing an unwanted extension. It can occur when a system:
- Trusts filenames rather than file contents.
- Allows a server-executable type into a web-accessible location.
- Validates one representation of a file but processes another.
- Allows archive extraction without safe path controls.
- Permits a file to be uploaded and later interpreted by a powerful backend service.
- Gives uploaded content access to a deployment, processing, or execution path.
This same multi-stage risk exists in Bing Images. A file can be accepted safely by one layer, then become dangerous when a later helper parses it in a different way.
The Autonomous Discovery Angle Is Significant—But Needs Perspective
XBOW has said its autonomous system found the three vulnerabilities, and the findings placed the company in the top 10 of Microsoft’s bug bounty leaderboard. The company describes this as the first appearance of an AI system in that ranking.That claim is noteworthy because the research was not based on a trivial, known pattern match. The process reportedly involved observing a blind backend fetch, interpreting inconsistent server responses, eliminating alternate hypotheses, identifying a likely conversion stack, mapping which input paths were enabled, and validating execution safely through controlled callbacks.
In other words, the reported achievement was not simply generating a payload. It was sustaining a multi-step investigation through ambiguity and dead ends.
What This Changes for Defenders
The immediate concern is not that autonomous systems have suddenly made every service trivially hackable. Security research still depends on scope, authorization, validation, expert review, and responsible disclosure. Many target environments are hardened, monitored, and difficult to understand remotely.The more realistic shift is one of speed and persistence.
An automated offensive system can test large numbers of variations, keep detailed records of results, revisit weak signals, and continue methodically where a human researcher might stop because a single issue appears low severity. That is particularly relevant to parser and workflow vulnerabilities, where no individual clue is conclusive.
Defensive teams should assume that attackers will increasingly use automation to:
- Enumerate public upload and conversion endpoints.
- Probe inconsistencies in file handling.
- Test alternate file signatures and format variants.
- Discover SSRF-style server-side fetch behavior.
- Map error responses and processing differences.
- Chain small misconfigurations into high-impact exploit paths.
The Risk of Overhyping AI-Found Vulnerabilities
There is also a necessary note of caution. Claims about autonomous discovery should be evaluated based on the verified vulnerability, the quality of the evidence, the vendor’s remediation, and the reproducibility of the result—not on marketing language alone.The lasting importance of this story is not whether a machine or a person took the final investigative step. It is that a familiar flaw class—unsafe interpretation of untrusted file content—persisted inside a modern, globally exposed cloud workflow.
Automation may have accelerated the discovery. The underlying engineering lesson remains longstanding and universal.
What Bing Users Need to Do
For ordinary Bing users, the required action is simple: nothing.The affected systems were Microsoft-hosted services, and the remediation was deployed server-side. These were not vulnerabilities in the Bing app, Microsoft Edge, Windows 11, Windows Server installations owned by customers, or user accounts.
That means users do not need to:
- Install a standalone patch for these CVEs.
- Change Bing account credentials.
- Stop using reverse image search.
- Remove images from their devices.
- Run antivirus scans specifically because of this disclosure.
What Administrators and Developers Should Do Now
The Microsoft Bing Images vulnerabilities should prompt organizations to review their own image upload, document preview, media conversion, and server-side URL retrieval workflows.The highest-value changes are architectural. Blocking one file extension is useful, but it is not enough if a conversion library identifies content by magic bytes, follows embedded references, or supports a broader set of formats than the application team intends.
1. Reduce Supported Formats Aggressively
Public-facing services should accept only the formats they truly require.For many applications, that means limiting uploads to raster formats such as:
- JPEG
- PNG
- WebP
- AVIF, where supported and required
Do not rely only on file extensions. Validate the actual content, normalize it safely, and reject ambiguous or polyglot files.
2. Configure Image Libraries for a Hostile Environment
Use a restrictive security policy for every image-processing deployment that handles untrusted data.Key controls include:
- Disable external delegates and shell-invoking behavior.
- Disable pipe-based command paths.
- Block indirect file reads and unexpected protocol handlers.
- Turn off unsupported coders and modules.
- Prevent converters from accessing arbitrary local paths.
- Set strict resource ceilings for memory, CPU time, dimensions, file size, and frame count.
- Keep conversion libraries and dependent interpreters fully patched.
policy.xml and delegates.xml are not administrative afterthoughts. In media-processing stacks, they are often core security controls.3. Isolate Every Conversion Job
Assume that a malicious file may trigger a parser vulnerability despite validation and policy controls.A safer conversion architecture includes:
- A dedicated low-privilege service account.
- Containers or sandboxes designed for hostile content.
- Read-only filesystem access where possible.
- Ephemeral worker instances.
- No access to sensitive credentials by default.
- Minimal mounted volumes.
- Seccomp, AppArmor, SELinux, Windows Defender Application Control, or comparable restrictions where applicable.
- Strict process and job-object limitations on Windows.
4. Restrict Outbound Network Access
Outbound network controls would not necessarily eliminate every parser flaw, but they can materially reduce impact.A conversion worker processing untrusted files rarely needs unrestricted internet access. Apply egress rules so it cannot freely reach:
- Internal administrative services.
- Cloud metadata endpoints.
- Private address ranges.
- Domain controllers.
- Sensitive API endpoints.
- Unapproved external destinations.
5. Treat Server-Side URL Fetching as a Separate Security Boundary
Any feature that retrieves a user-provided URL requires defense against SSRF and malicious content delivery.At a minimum:
- Permit only approved schemes, typically
https. - Validate destinations after DNS resolution, not just before it.
- Block loopback, link-local, private, and reserved address ranges.
- Revalidate every redirect target.
- Apply short timeouts and size limits.
- Restrict response types and enforce content limits.
- Route fetches through a controlled network egress layer.
- Scan and transform fetched files in the same isolated environment used for uploads.
6. Monitor for the Signals That Matter
Security monitoring should include more than web-server logs.Useful indicators include:
- Unexpected child processes from image-processing services.
- Command interpreters started by converter workers.
curl, PowerShell,cmd.exe,bash, or scripting hosts launched from media pipelines.- Outbound requests from thumbnailing or rendering containers.
- Repeated conversion failures tied to SVG, XML, EPS, or unusual MIME types.
- Sudden growth in worker crashes, 500 responses, or parser exceptions.
- Unusual DNS requests from services that should not need DNS resolution.
The Bigger Lesson: Ordinary Features Create Extraordinary Trust Boundaries
The Bing Images vulnerabilities are a reminder that the most damaging bugs often hide behind completely normal product features. Reverse image search is not exotic. File uploads are not exotic. Thumbnail generation, metadata stripping, document previews, and remote image fetching are routine parts of modern web services.Yet each feature can activate powerful parsing and conversion behavior on the backend.
The fixes to Bing Images remove the immediate risk to users of Microsoft’s service. The broader warning remains: untrusted content is active input, even when it looks like a picture.
Organizations that treat image processing as a privileged, networked, feature-rich parser environment—and secure it accordingly—will be far better prepared for the next vulnerability that begins with nothing more suspicious than an uploaded image.
References
- Primary source: cyberkendra.com
Published: 2026-07-24T17:22:00+00:00
Bing Images Bugs Let Anyone Run Code as SYSTEM - Cyber Kendra
Microsoft patched three critical RCE flaws found by XBOW's AI, including two in Bing Images that executed commands as SYSTEM.www.cyberkendra.com - Related coverage: thehackerwire.com
Critical Command Injection in Microsoft Bing Images – TheHackerWire
Summary CVE-2026-32194 identifies a critical command injection vulnerability in Microsoft Bing Images. Published on March 19, 2026, this flaw carries a CVSS ...www.thehackerwire.com
