CVE-2023-40217

mediumpriority · track · 21EPSS 0.008 · 56 %ileCHDEEUFRRUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.80% (56th) EPSS
CVSS 5.3 · medium
Is it mine?
117 products
Check your exposure
Who says so?
9 sources
cnnvd · enisa_euvd · fstec_bdu · osv

EPSS · scored 2026-10-27

An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)

01

remediations

Vendor fix, mitigation, or workaround guidance, as published by each source.

A vendor fix is available.

  • Fixedphoenix_contact_psirt

    Update to the latest 2024.0.6 LTS Firmware Release. PHOENIX CONTACT recommends to always use an up-to-date version of the PLCnext Engineer.

  • MitigationARM600abb_psirt

    Mitigating factors describe conditions and circumstances that make an attack that exploits the vulnerability difficult or less likely to succeed. The following mitigations are recommended. 1. Obtain a cellular private access point (APN). A dedicated private cellular access point and respective SIM card subscriptions can be requested from your cellular service provider. This service doesn’t expose the traffic between remote sites and main site to the internet but rather uses cellular operator’s private wide area network (WAN). Therefore, the ARM600 wouldn’t need open ports to the internet. 2. Avoid exposing any system component to the internet. If, however, the ARM600 is exposed to the internet, only the VPN port should be opened towards the internet (e.g., Patrol management connections can be configured to use VPN tunnel and remote administration connections can be implemented by using OpenVPN PC-client). 4. Perform firewall configuration by the "allowlisting" principle, i.e., explicitly allowing only the required ports and protocols and blocking any other traffic. 6. If the internet is used as a WAN media for carrying VPN tunnels, use Demilitarized Zone (DMZ) for terminating connections from the internet (i.e., the remote connections should terminate to the DMZ network, which would be segregated from other networks by a firewall. The ARM600 server would be located into this DMZ). 7. Change the default user credentials of ARM600 and Arctic wireless gateways into non-defaults and use complex non-guessable passwords with special characters. Do not reuse passwords within the system. 8. Use administrator (i.e., root user) privileges only when required by the task. 9. Supporting systems, such as PCs used for configuration, should be frequently updated. If possible, use dedicated site PCs for upgrading and engineering purposes. At minimum, PCs should be investigated by running a full virus scan with recently updated signature files before introducing the PC to the OT system. Any data, such as device configurations and firmware update files transferred to the Arctic system should be virus scanned prior to transferring. 10. Introduce a backup policy, which will ensure periodical backups and backup revision numbering. Consider the following: a. Check that the entire system has backups available from all applicable parts. b. Store the backups in a safe place (e.g. in an encrypted storage), restricted by role-based access control mechanisms. c. Ensure the security of the configuration PCs that may have local copies of device configurations. d. Validate the backups to make sure that they’re working. 11. Follow cyber security best practices for installation, operation, and decommissioning as described in the product’s Cyber Security Deployment Guideline and User Manual. 12. Use continuous monitoring (e.g., intrusion detection/prevention tools) to detect anomalies in the system 13. Consider hardening the system according to the following: a. Remove any unnecessary communication links in the system. b. If possible, close unused physical ports. c. Open only the necessary TCP/UDP ports in the configuration. d. Remove all unnecessary user accounts. e. Restrict traffic by firewall. f. Allow the traffic only from/to necessary hosts' IP addresses (i.e., define both source and destination in the firewall rules, where possible). g. Define client IP address as allowed address in SCADA communication protocols, if such configuration is supported. h. Remove or deactivate all unused processes, communication ports and services, where possible. i. Use physical access controls to the system installations (e.g., to server rooms and device cabinets).

  • MitigationSWabb_psirt

    Mitigating factors describe conditions and circumstances that make an attack that exploits the vulnerability difficult or less likely to succeed. The following mitigations are recommended. 1. Obtain a cellular private access point (APN). A dedicated private cellular access point and respective SIM card subscriptions can be requested from your cellular service provider. This service doesn’t expose the traffic between remote sites and main site to the internet but rather uses cellular operator’s private wide area network (WAN). Therefore, the ARM600 wouldn’t need open ports to the internet. 2. Avoid exposing any system component to the internet. If, however, the ARM600 is exposed to the internet, only the VPN port should be opened towards the internet (e.g., Patrol management connections can be configured to use VPN tunnel and remote administration connections can be implemented by using OpenVPN PC-client). 4. Perform firewall configuration by the "allowlisting" principle, i.e., explicitly allowing only the required ports and protocols and blocking any other traffic. 6. If the internet is used as a WAN media for carrying VPN tunnels, use Demilitarized Zone (DMZ) for terminating connections from the internet (i.e., the remote connections should terminate to the DMZ network, which would be segregated from other networks by a firewall. The ARM600 server would be located into this DMZ). 7. Change the default user credentials of ARM600 and Arctic wireless gateways into non-defaults and use complex non-guessable passwords with special characters. Do not reuse passwords within the system. 8. Use administrator (i.e., root user) privileges only when required by the task. 9. Supporting systems, such as PCs used for configuration, should be frequently updated. If possible, use dedicated site PCs for upgrading and engineering purposes. At minimum, PCs should be investigated by running a full virus scan with recently updated signature files before introducing the PC to the OT system. Any data, such as device configurations and firmware update files transferred to the Arctic system should be virus scanned prior to transferring. 10. Introduce a backup policy, which will ensure periodical backups and backup revision numbering. Consider the following: a. Check that the entire system has backups available from all applicable parts. b. Store the backups in a safe place (e.g. in an encrypted storage), restricted by role-based access control mechanisms. c. Ensure the security of the configuration PCs that may have local copies of device configurations. d. Validate the backups to make sure that they’re working. 11. Follow cyber security best practices for installation, operation, and decommissioning as described in the product’s Cyber Security Deployment Guideline and User Manual. 12. Use continuous monitoring (e.g., intrusion detection/prevention tools) to detect anomalies in the system 13. Consider hardening the system according to the following: a. Remove any unnecessary communication links in the system. b. If possible, close unused physical ports. c. Open only the necessary TCP/UDP ports in the configuration. d. Remove all unnecessary user accounts. e. Restrict traffic by firewall. f. Allow the traffic only from/to necessary hosts' IP addresses (i.e., define both source and destination in the firewall rules, where possible). g. Define client IP address as allowed address in SCADA communication protocols, if such configuration is supported. h. Remove or deactivate all unused processes, communication ports and services, where possible. i. Use physical access controls to the system installations (e.g., to server rooms and device cabinets).

  • MitigationARM600cisa_csaf_ot

    Mitigating factors describe conditions and circumstances that make an attack that exploits the vulnerability difficult or less likely to succeed. The following mitigations are recommended. 1. Obtain a cellular private access point (APN). A dedicated private cellular access point and respective SIM card subscriptions can be requested from your cellular service provider. This service doesn’t expose the traffic between remote sites and main site to the internet but rather uses cellular operator’s private wide area network (WAN). Therefore, the ARM600 wouldn’t need open ports to the internet. 2. Avoid exposing any system component to the internet. If, however, the ARM600 is exposed to the internet, only the VPN port should be opened towards the internet (e.g., Patrol management connections can be configured to use VPN tunnel and remote administration connections can be implemented by using OpenVPN PC-client). 4. Perform firewall configuration by the "allowlisting" principle, i.e., explicitly allowing only the required ports and protocols and blocking any other traffic. 6. If the internet is used as a WAN media for carrying VPN tunnels, use Demilitarized Zone (DMZ) for terminating connections from the internet (i.e., the remote connections should terminate to the DMZ network, which would be segregated from other networks by a firewall. The ARM600 server would be located into this DMZ). 7. Change the default user credentials of ARM600 and Arctic wireless gateways into non-defaults and use complex non-guessable passwords with special characters. Do not reuse passwords within the system. 8. Use administrator (i.e., root user) privileges only when required by the task. 9. Supporting systems, such as PCs used for configuration, should be frequently updated. If possible, use dedicated site PCs for upgrading and engineering purposes. At minimum, PCs should be investigated by running a full virus scan with recently updated signature files before introducing the PC to the OT system. Any data, such as device configurations and firmware update files transferred to the Arctic system should be virus scanned prior to transferring. 10. Introduce a backup policy, which will ensure periodical backups and backup revision numbering. Consider the following: a. Check that the entire system has backups available from all applicable parts. b. Store the backups in a safe place (e.g. in an encrypted storage), restricted by role-based access control mechanisms. c. Ensure the security of the configuration PCs that may have local copies of device configurations. d. Validate the backups to make sure that they’re working. 11. Follow cyber security best practices for installation, operation, and decommissioning as described in the product’s Cyber Security Deployment Guideline and User Manual. 12. Use continuous monitoring (e.g., intrusion detection/prevention tools) to detect anomalies in the system 13. Consider hardening the system according to the following: a. Remove any unnecessary communication links in the system. b. If possible, close unused physical ports. c. Open only the necessary TCP/UDP ports in the configuration. d. Remove all unnecessary user accounts. e. Restrict traffic by firewall. f. Allow the traffic only from/to necessary hosts' IP addresses (i.e., define both source and destination in the firewall rules, where possible). g. Define client IP address as allowed address in SCADA communication protocols, if such configuration is supported. h. Remove or deactivate all unused processes, communication ports and services, where possible. i. Use physical access controls to the system installations (e.g., to server rooms and device cabinets).

  • MitigationSWcisa_csaf_ot

    Mitigating factors describe conditions and circumstances that make an attack that exploits the vulnerability difficult or less likely to succeed. The following mitigations are recommended. 1. Obtain a cellular private access point (APN). A dedicated private cellular access point and respective SIM card subscriptions can be requested from your cellular service provider. This service doesn’t expose the traffic between remote sites and main site to the internet but rather uses cellular operator’s private wide area network (WAN). Therefore, the ARM600 wouldn’t need open ports to the internet. 2. Avoid exposing any system component to the internet. If, however, the ARM600 is exposed to the internet, only the VPN port should be opened towards the internet (e.g., Patrol management connections can be configured to use VPN tunnel and remote administration connections can be implemented by using OpenVPN PC-client). 4. Perform firewall configuration by the "allowlisting" principle, i.e., explicitly allowing only the required ports and protocols and blocking any other traffic. 6. If the internet is used as a WAN media for carrying VPN tunnels, use Demilitarized Zone (DMZ) for terminating connections from the internet (i.e., the remote connections should terminate to the DMZ network, which would be segregated from other networks by a firewall. The ARM600 server would be located into this DMZ). 7. Change the default user credentials of ARM600 and Arctic wireless gateways into non-defaults and use complex non-guessable passwords with special characters. Do not reuse passwords within the system. 8. Use administrator (i.e., root user) privileges only when required by the task. 9. Supporting systems, such as PCs used for configuration, should be frequently updated. If possible, use dedicated site PCs for upgrading and engineering purposes. At minimum, PCs should be investigated by running a full virus scan with recently updated signature files before introducing the PC to the OT system. Any data, such as device configurations and firmware update files transferred to the Arctic system should be virus scanned prior to transferring. 10. Introduce a backup policy, which will ensure periodical backups and backup revision numbering. Consider the following: a. Check that the entire system has backups available from all applicable parts. b. Store the backups in a safe place (e.g. in an encrypted storage), restricted by role-based access control mechanisms. c. Ensure the security of the configuration PCs that may have local copies of device configurations. d. Validate the backups to make sure that they’re working. 11. Follow cyber security best practices for installation, operation, and decommissioning as described in the product’s Cyber Security Deployment Guideline and User Manual. 12. Use continuous monitoring (e.g., intrusion detection/prevention tools) to detect anomalies in the system 13. Consider hardening the system according to the following: a. Remove any unnecessary communication links in the system. b. If possible, close unused physical ports. c. Open only the necessary TCP/UDP ports in the configuration. d. Remove all unnecessary user accounts. e. Restrict traffic by firewall. f. Allow the traffic only from/to necessary hosts' IP addresses (i.e., define both source and destination in the firewall rules, where possible). g. Define client IP address as allowed address in SCADA communication protocols, if such configuration is supported. h. Remove or deactivate all unused processes, communication ports and services, where possible. i. Use physical access controls to the system installations (e.g., to server rooms and device cabinets).

02

cvss

Technical severity, 0–10. One row per scoring source.

8.6
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 4.9–8.6

v3.15.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Nprimary · NVD / NIST USexploitability 3.9 · impact 1.4
v3.15.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:W/RC:Csecondary · CISA US
v3.18.6highAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:Nsecondary · FSTEC (BDU) RU
v3.15.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Nsecondary · Phoenix Contact PSIRT DE
v3.14.9mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:Usecondary · CVSS-BT (t0sche)
v3.15.3mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:W/RC:Csecondary · ABB PSIRT
03

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: none · Automatable: yes · Technical Impact: partialcoordinatorcisa_ssvcUS
04

weaknesses

The CWE weakness classes this flaw belongs to.

05

affected products (117)

Products and version ranges known to be affected.

06

advisories (12)

Vendor and ecosystem advisories describing this.

  • 2NGA002579ABB Arctic communication solution ARM600 Vulnerabilities2025-04-07csaf · abb_psirtCH

    ABB is aware of public reports of a vulnerabilities in product versions listed as affected in this advisory. An attacker who successfully exploited these vulnerabilities could cause the product to stop, make the product inacces-sible, take remote control of the product or insert and run arbitrary code. As part of ABB product lifecycle policy, once a product transitions to end-of-life, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document, such as using a private APN cellular network between Arctic wireless gateways and ARM600 for establishing VPN tunnels, to mitigate security risks and avoid potential vulnerabilities. As part of ABB product lifecycle policy, once a product transitions to Limited state, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document to mitigate security risks.

  • VDE-2024-073Phoenix Contact: Multiple Vulnerabilities in PLCnext Firmware2024-12-09csaf · phoenix_contact_psirtDE

    Multiple Linux component vulnerabilities fixed in latest PLCnext Firmware release 2024.0.6 LTS

  • WID-SEC-W-2023-2173Python: Schwachstelle ermöglicht Umgehung von SicherheitsmechanismenDeutsch2023-08-24csaf · cert_bundDE

    Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Python ausnutzen, um Sicherheitsmechanismen zu umgehen oder andere Auswirkungen zu erzielen.

  • WID-SEC-W-2023-2850IBM AIX: Mehrere SchwachstellenDeutsch2023-11-07csaf · cert_bundDE

    Ein Angreifer kann mehrere Schwachstellen in IBM AIX ausnutzen, um Sicherheitsmaßnahmen zu umgehen oder einen Denial-of-Service-Zustand zu verursachen.

  • WID-SEC-W-2024-0794Dell ECS: Mehrere SchwachstellenDeutsch2024-04-04csaf · cert_bundDE

    Ein Angreifer kann mehrere Schwachstellen in Dell ECS ausnutzen, um seine Privilegien zu erweitern, beliebigen Programmcode mit Administratorrechten auszuführen, Informationen offenzulegen, Dateien zu manipulieren, einen Cross-Site-Scripting-Angriff durchzuführen, Sicherheitsvorkehrungen zu umgehen oder einen Denial of Service Zustand herbeizuführen.

  • WID-SEC-W-2024-3377Dell PowerProtect Data Domain: Mehrere SchwachstellenDeutsch2024-11-07csaf · cert_bundDE

    Ein lokaler Angreifer kann mehrere Schwachstellen in Dell PowerProtect Data Domain ausnutzen, um seine Privilegien zu erhöhen, Informationen offenzulegen und um nicht näher beschriebene Auswirkungen zu erzielen.

  • ICSA-25-105-08ABB M2M Gateway2025-04-07icsa · cisa_csaf_otUS

    ABB is aware of public reports of a vulnerabilities in product versions listed as affected in this advisory. An attacker who successfully exploited these vulnerabilities could cause the product to stop, make the product inacces-sible, take remote control of the product or insert and run arbitrary code. As part of ABB product lifecycle policy, once a product transitions to end-of-life, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document, such as using a private APN cellular network between Arctic wireless gateways and ARM600 for establishing VPN tunnels, to mitigate security risks and avoid potential vulnerabilities. As part of ABB product lifecycle policy, once a product transitions to Limited state, we discontinue maintenance, security patches, and technical support to focus on current and future technologies. While the product will continue to function, we strongly recommend implementing mitigations defined in this document to mitigate security risks.

  • BIT-libpython-2023-402172025-08-11vendor · osvUS

    An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)

  • BIT-python-2023-402172024-03-06vendor · osvUS

    An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)

  • BIT-python-min-2023-402172025-01-16vendor · osvUS

    An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)

  • CERTFR-2026-AVI-1385Multiples vulnérabilités dans les produits VMwareFrançais2026-10-26vendor · certfrFR
  • PSF-2023-8Bypass TLS handshake on closed sockets2023-08-24vendor · osvUS

    Instances of `ssl.SSLSocket` are vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data. The vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred. ### Affected usages This vulnerability **primarily affects** HTTPS servers and other server-side protocols using TLS client authentication due to requiring reading data immediately after the handshake to be vulnerable. Operations which would fail on a closed socket (like sending data) immediately after the handshake **are not affected by this vulnerability.** Because disconnecting the socket is a necessary step to trigger the vulnerability **there is no risk of data exfiltration or data leakage directly from the malicious TLS connection**, however the vulnerability does carry risk for modifying or deleting resources which are authenticated using only TLS client certificates. This vulnerability **affects** clients who are reading and processing data from the server after a TLS handshake without sending any data first. Our team is unaware of a protocol that uses TLS that fits this usage pattern. This vulnerability **does not affect** client-side HTTPS connections like pip or requests as an HTTP request must be sent before an HTTP response is read meaning the connection would already be closed by the time the client is sending an HTTP request, leading to an error. This vulnerability **affects, but has no impact** on servers that aren’t using TLS client certificate authentication as traffic to a non-authenticating TLS server loses nothing from a bypassed handshake to inject a query and close the connection as the same action could be taken by a peer using a TLS connection with a proper handshake.

07

also known as (8)

Other names and identifiers for this entity.

08

sources

Which sources assert this record, and when.

09

references (31)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan