Facebook HHVM permits deprecated TLS in stream connections

HHVM 4.172.0 and all prior versions use TLS 1.0 for secure connections when handling tls:// URLs in the stream extension. TLS1.0 has numerous published vulnerabilities and is deprecated. HHVM 4.153.4, 4.168.2, 4.169.2, 4.170.2, 4.171.1, 4.172.1, 4.173.0 replaces TLS1.0 with TLS1.3. Applications that call stream_socket_server or stream_socket_client functions with a URL starting with tls:// are affected.

The source description states that HHVM 4.172.0 and all prior versions are affected when an application uses the relevant stream functions with a tls:// URL.

• The structured affected data marks 4.172.0 through less than 4.172.1, 4.171.0 through less than 4.171.1, 4.170.0 through less than 4.170.2, and 4.169.0 through less than 4.169.2 as affected.
• It also marks versions below 4.153.4 as affected and identifies 4.153.4 as a fix.
• The record for the branch beginning at 4.154.0 contains lessThan 1.168.2, an inconsistent boundary compared with the other branch entries. The exact exposure range for that branch therefore cannot be determined reliably from the supplied structured data.
• The supplied description lists 4.153.4, 4.168.2, 4.169.2, 4.170.2, 4.171.1, 4.172.1, and 4.173.0 as releases that replace the legacy protocol. The vendor advisory reviewed directly announces patch releases 4.153.4, 4.168.2, and 4.172.1, and does not enumerate the same complete set of branches. This difference should be preserved when assessing individual packages.

Facebook HHVM processes tls:// URLs in the stream extension through stream_socket_server and stream_socket_client. Before the fix, the client and server paths selected version-specific TLS methods that allowed negotiation of a legacy TLS protocol. The patch changes those selections to more general TLS methods, while the vendor advisory describes the result as permitting only newer TLS connections. The relevant input is a URL beginning with tls://; whether an attacker can influence that URL is deployment-specific and is not established by the available evidence. Exposure applies to applications using these functions with the tls:// scheme, not merely to every process running HHVM. The available sources do not establish every library-level negotiation detail after the update.

The affected behavior is reached through network connections created by an application through the stream extension. The structured record characterizes the conditions as remotely reachable over the network, requiring no authentication or user interaction and having low complexity. Practical exploitability still depends on whether the deployment creates affected tls:// connections and whether an attacker can influence the connection or TLS session. The supplied record sets public_exploit to false and known_exploited to null; those fields describe the available metadata and do not prove that exploitation has never occurred. None of the reviewed sources identifies a named public exploit, campaign, or observed exploitation.

The vulnerability allows stream connections to use a legacy TLS protocol with weaker protection. If an attacker can exploit weaknesses in that protocol or the conditions of the connection, the confidentiality and integrity of transported data may be affected. Organisational consequences depend on the data, endpoints, and services carried over the connection; the record does not describe a separate privilege-escalation or code-execution path. The available evidence does not show that a specific breach or service-availability loss occurred.

Allowing a legacy TLS protocol can reduce cryptographic protection for data carried through an application's stream connections. Depending on the traffic, connection settings, and attacker capability, consequences may include exposure or modification of data in an affected session. Applications carrying sensitive data over tls:// should be prioritized because upgrading may affect the security of those communication paths. The available evidence does not confirm an actual breach, data loss, or service outage.

1. Upgrade the affected branch to a patch release explicitly announced by the vendor advisory: 4.153.4, 4.168.2, or 4.172.1, as applicable to the deployed branch.
2. For branches where the supplied record additionally lists 4.169.2, 4.170.2, 4.171.1, or 4.173.0, verify the corresponding release and package metadata before treating that branch as vendor-confirmed fixed. Do not extend a fix from one branch to another.
3. The supplied description says that the fix replaces TLS1.0 with TLS1.3; the vendor advisory uses the more cautious wording that only newer TLS connections are permitted.
4. If an upgrade is not immediately possible, the available evidence does not document a vendor-provided workaround or configuration mitigation. Prioritize upgrade planning and identify every application that still depends on the affected tls:// calls.

1. Inventory the HHVM versions actually running and compare them with each affected branch rather than checking only the product name.
2. Review application source and configuration for stream_socket_server or stream_socket_client calls using URLs that begin with tls://.
3. Inspect TLS handshake telemetry or observations at a proxy to identify connections still negotiating a legacy TLS protocol. This is a precautionary check, not a vendor-defined IOC.
4. Verify the runtime version used by workers, containers, or hosts that process these calls; do not infer safety from a version declared only in a manifest.
5. The available evidence does not provide a specific log event, log path, or IOC for this issue. Absence of such evidence does not demonstrate that a deployment is safe.