Design flaw in AS3 socket handling allows port probing

Update October 15, 2008: The release of Flash Player Version 10 fixes the problem.


Due to a design flaw in ActionScript 3 socket handling, compiled Flash movies are able to scan for open TCP ports on any host reachable from the host running the SWF, bypassing the Flash Player Security Sandbox Model and without the need to rebind DNS.

Technical background

In AS3 Adobe introduced a new socket-related event called SecurityErrorEvent. This event is always thrown when a Flash Player tries to connect to a socket that it is not allowed to connect to.

The Problem with the SecurityErrorEvent is that it's thrown immediately when a Flash Player tries to connect to a closed TCP port. If a service is listening on that port the Flash Player writes the string "<policy-file-request/>" and waits for response from the service. Nearly no TCP-service will respond to this request.

We can assume the following: When trying to connect to a socket that the SWF is not allowed to and it doesn't get a SecurityErrorEvent within 2 seconds the port is most likely open.

A new Flash player instance is used for every probed port because the Flash Player sends only one policy-file request per player per host per port.

Tested Platforms

Works on:

Doesn't work as expected on:

Known limitations

Disclosure Timeline

Possible Fixes

Flash-Player Side (Adobe)

User Side



The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2007-4324 to this issue. This is a candidate for inclusion in the CVE list (, which standardizes names for security problems.

Additional Notes

Adobe released an article at the knowledge base regarding that issue: Socket connection timing can reveal information about network configuration (Flash Player).

Live PoC scanner

Host to scan:


Start Scan

Source Code (compile using Adobes Flex2 SDK)