#memorycorruption

Read Time:3 Minute, 35 Second

A Vulnerability That Strikes Before LoginA newly disclosed flaw in the TightVNC Viewer for Windows allows an attacker to execute arbitrary code on a victim’s machine before any password prompt or authentication step takes place. The research, credited to SeongJoon Cho of SSD Labs Korea, comes with a working proof-of-concept exploit built against TightVNC Viewer 2.8.88 x64, turning what might otherwise look like a theoretical bug into a demonstrated attack chain.

It is worth stressing which component is at risk. This is not a flaw in computers running a TightVNC server; it affects the viewer application that connects out to remote desktops. An attacker needs either network access to a viewer sitting in “Listening Mode” or the ability to lure a user into pointing their viewer at a server the attacker controls.

How a Screen-Size Field Becomes a WeaponThe root cause lies in how TightVNC handles the Remote Framebuffer protocol (RFB), the standard VNC uses to describe a remote screen. When a server announces its resolution, the viewer calculates how much memory it needs to store that image and stuffs the result into a 32-bit integer. Feed it a sufficiently large resolution, and that calculation wraps around, silently handing back a far smaller memory allocation than the screen actually requires.

In the documented proof-of-concept, a malicious server claims a screen measuring 32,768 by 32,769 pixels at 32 bits per pixel — an image that would require more than 4 GB to store. The viewer, fooled by the integer overflow, allocates only 128 KB. When the server then sends screen-update data, the viewer happily writes it past the end of that undersized buffer, corrupting adjacent memory.

From Memory Corruption to Code ExecutionMemory corruption alone doesn’t guarantee an attacker can run their own code, but the published exploit shows how to get there. It first manipulates the length of an outgoing buffer to leak nearby memory contents, which reveals addresses an attacker needs to defeat Windows’ address space layout randomization (ASLR). From there, it hijacks a function pointer and strings together fragments of existing code — a technique known as return-oriented programming — to ultimately call Windows’ own CreateProcessW function and launch an arbitrary process.

Two paths bring a victim into range. A viewer left in Listening Mode exposes TCP port 5500 and, according to the disclosure, accepts inbound connections with no password and no IP filtering by default — meaning anyone who can reach that port can attempt the attack directly. Alternatively, a user who connects their own viewer outward to a rogue “support” server hands the same opportunity to whoever controls that server. Either way, the compromise happens before credentials are ever checked.

Not the Same as Password-Guessing AttacksThis bug is distinct from the VNC session hijacking that results from weak or reused passwords, and it’s also unrelated to cases where attackers trick victims into installing fake remote-access tools disguised as legitimate software. Here, the flaw lives inside the memory-handling logic of a trusted application, which is what makes a pre-authentication exploit possible in the first place.

Patch Status and What to Do NowResearchers say they received no response from the vendor before disclosure. TightVNC’s own release notes point to security updates issued around October 2 and October 5, 2026, slightly muddying the exact patch timeline, but the vendor confirms that versions 2.8.89 and 2.8.90 close the viewer-side issues, with 2.8.90 recommended for anyone on that branch.

There is no evidence yet of active exploitation in the wild, but with public proof-of-concept code now available, that can change quickly. Security teams should treat this as urgent:

Update every TightVNC Viewer installation to version 2.8.90 as soon as possible.

Disable Listening Mode wherever it isn’t actively required.

Restrict access to TCP port 5500 to trusted hosts only, using firewall rules.

Avoid connecting viewers to unfamiliar or unverified VNC servers, including unsolicited “remote support” sessions.

Network-level restrictions reduce exposure but are not a substitute for patching the vulnerable viewer itself — until the update is applied, a reachable port or a single outbound connection to the wrong server is enough to hand an attacker code execution on the underlying Windows host.

Read Time:3 Minute, 19 Second

Google has released a Chrome Stable security update that addresses ten vulnerabilities across Windows, macOS and Linux. The group includes one critical flaw, six high-severity issues and three medium-severity bugs spread across several browser components. The most urgent repair is for a use-after-free condition in Chrome’s Prerender functionality.

The fixed builds are Chrome 155.0.8059.84 and .85 for Windows and macOS, and 155.0.8059.84 for Linux. Distribution is staged, so not every device will see the update simultaneously. Users can prompt a check from Chrome’s About page and should restart the browser when requested, because downloading an update without relaunching leaves the old process running.

Critical flaw affects the Prerender featureCVE-2026-110922 is a critical use-after-free vulnerability reported by researcher Xinyang Ge on October 2. This class of defect occurs when software releases a region of memory but later continues to reference it. An attacker who can manipulate the stale reference may trigger a crash or corrupt memory, sometimes creating a path toward code execution.

Google has not published detailed exploitation mechanics and has not said that the flaw is being used in active attacks. Restricting technical information during rollout is a common protective measure: it gives the majority of users time to update before complete details make reliable exploit development easier. The lack of reported exploitation, however, is not a reason to postpone an available critical patch.

The release also fixes CVE-2026-110913, a high-severity memory-corruption issue in the Document Object Model, which represents and controls the structure of web pages. Ge reported the issue with assistance from Anthropic and its Claude AI system. The credit is notable, although Google’s advisory does not describe whether the model discovered the bug, helped analyze it or assisted with another part of the research process.

V8, SVG and Core receive high-severity fixesFive additional high-severity problems affect foundational browser components. CVE-2026-110919 and CVE-2026-110921 are use-after-free flaws in V8, Chrome’s JavaScript engine. CVE-2026-110920 is another V8 memory-corruption issue. Google repaired CVE-2026-110918 in Core, while researcher C0rk1 reported CVE-2026-110917 in SVG.

The three medium-severity vulnerabilities round out the update: CVE-2026-110916 involves insufficient input validation in Desktop, CVE-2026-110915 is a use-after-free issue in Compositing, and CVE-2026-110914 concerns memory corruption in Workers. Together, the ten fixes show that this is not a patch for one isolated subsystem.

Critical: CVE-2026-110922 in Prerender.

High: CVE-2026-110913 in DOM and five flaws across V8, Core and SVG.

Medium: three issues in Desktop, Compositing and Workers.

Google also noted that its internal security work uses memory-safety and fuzzing tools including AddressSanitizer, MemorySanitizer, libFuzzer and AFL. These tools exercise software with unusual inputs and monitor execution for memory errors that conventional functional tests may not reveal.

Enterprises should verify deployment, not assume itFor individuals, the practical response is to update and relaunch. Managed environments need an additional verification step. Administrators should confirm that device-management reporting shows the corrected build on Windows, macOS and Linux endpoints, investigate machines that remain behind policy, and account for browsers that have been left open for long periods.

Because Chromium code is used by multiple browser products, security teams should also watch their respective vendors for applicable releases and version guidance rather than assuming that updating Google Chrome fixes every Chromium-based browser installed in the organization.

Browser vulnerabilities are attractive because malicious web content can reach large numbers of users with little friction. Rapid installation narrows that opportunity. Security teams should communicate the required restart clearly and track exceptions until every managed endpoint reports compliance. With a critical memory flaw at the top of this release and multiple high-severity issues underneath it, organizations should treat Chrome 155.0.8059.84 or later as the new minimum secured baseline.