With the advent of 4th industrial revolution the automation technology has undergone a rapid change. As a result new solutions has been introduced to the market to address new requirements and one of them are the next generation PLC devices. Since those devices are meant to be used in critical infrastructure where security is a high priority, we decided to perform a security assessment on them and our first choice was PLCNext AXC F 2152 made by Phoenix Contact.

PLCNext Control is an open platform controller with PLCnext Technology which makes it possible to implement automation projects without the limitations of proprietary systems. It works with IDEs such as Visual Studio, Eclipse, Matlab Simulink, and PC Worx Engineer and makes it possible to develop programs in IEC 61131-3, C/C++ and C#.

We first performed a static firmware analysis and then performed more in-depth dynamic analysis on the device and found two unknown vulnerabilities.


Analyzing the firmware:

Since the firmware was available on their web site, we started by analyzing it. The latest firmware version available on the web site at the time of the assessment was 1.10. We analyzed the firmware using our Firmalyzer Enterprise, automated firmware security analysis platform which gave us various results that we share some:


1. Vulnerable 3rd party components

The platform showed us the following known vulnerabilities for some 3rd party components inside the firmware:







CVE-2017-11108,  CVE-2017-11541, CVE-2017-11542,  CVE-2017-11543










CVE-2017-3735,  CVE-2017-3731, CVE-2017-3738,  CVE-2017-3737, CVE-2018-0737


CVE-2016-9840,  CVE-2016-9841, CVE-2016-9842,  CVE-2016-9843


CVE-2018-1000122,  CVE-2018-1000301, CVE-2017-8817,  CVE-2018-1000120, CVE-2018-1000121,  CVE-2016-9952, CVE-2016-9953, CVE-2017-1000101,  CVE-2017-8816, CVE-2017-1000254, CVE-2017-1000100,  CVE-2017-1000257, CVE-2018-1000005, CVE-2016-7141


CVE-2017-5334,  CVE-2017-5335, CVE-2017-5336,  CVE-2017-5337, CVE-2016-7444


CVE-2017-9023, CVE-2018-5388, CVE-2017-9022, CVE-2017-11185


CVE-2015-9251, CVE-2016-7103


2. Compiler security flags:

Firmalyzer’s binary analysis module showed that most of the binary executables compiled with disabled compiler security flags including Stack canary, ASLR and Read-only relocation. We hardly recommend them to be enabled in order to reduce or eliminate the risk of buffer overflows.


3. Secure Configuration Recommendations:

The platform showed us that the configuration files are not set based on the good practices and showed some recommendations for the following config files:



Nginx version number is sent in error pages and server header

Content-type sniffing is not prevented

The Cross-site scripting (XSS) filter is not enabled



PermitRootLogin is enabled, root can login directly,

SSH has no specific user or group limitation. Most likely all valid users can SSH to this machine.


/etc/init.d/rcS and /etc/profile

Default umask could be more strict like 027



Set mount option nosuid for /var


More in-depth analysis:

After analyzing the firmware, we started playing with the device to perform more in-depth analysis and ended up finding 2 vulnerabilities:


1. CVE-2019-10858: Escalation of Privileges & Information Disclosure

Since the configuration files ( including all of the critical configurations ) are stored in the SD card and the same SD card can be used in all of the PLCNext devices, the attacker can both read and change the configurations and set her own credentials just by changing the contents in the SD card and by putting the SD in any plcnext device she has physical access to even for a few seconds, without any authentication she can have root access to the device and is able to have further access to the device over the network or even remotely, behind the NAT for example using reverse ssh tunnel.

To have a root access to the device the attacker needs to access the SD card using a card reader, generate a shadow style password and add root user and generated password to the

“etc/plcnext/plcnext_shadow.sqlite” and “etc/plcnext/plcnext_users.sqlite” databases stored in the SD card. Then by inserting the card into the device she can have root access to the device. Even if the root user is set on the device which is not by default, this method overrides it. Also, the new user is not shown in the web interface and nothing is logged since the changes are happened separately on the SD.

The attacker can also have access to the other confidential data and perform changes on the other configuration files stored in SD such as changing the ssh keys with her own key or the certificate to access to the web interface with her own certificate.

In our opinion the score of the vulnerability is 6.8:


2. CVE-2019-10857: Denial of Service

When we tried testing a local man-in-the-middle attack between the PC WORX Engineer and the plcnext device, the attack was not successful but it caused the crash on the device and made the Plcnext service which is the main service run on the PLC stop.

When we traced the application to check for the cause, we found out when we try to connect to the device in that scenario it keeps showing an error until segfault happens. We did not dive into the binary to check for the details but that is definitely an infinite loop leads to segmentation fault and causes the app to be stopped.

Basically we tried to test for confidentiality and ended up triggering an availability issue which in OT environments is more important than confidentiality and integrity.

The crash happens even before asking for the credentials which is asked in the normal case. The only requirement for an attacker is being able to access the network that the PLCNext device is connected to. Then by simply running her own machine with PC WORX engineer and establishing a simple man-in-the-middle setup ( Arpspoofing + sslsplit ) between the machine and the PLCNext device and trying to connect to the device from the machine, she can trigger the vulnerability and stop the whole Plcnext service which can only be started again by doing a manual reset. It is just a simple way of triggering the vulnerability, but of course the attacker is normally able to send a crafted request to trigger the vulnerability. In our opinion the score of the vulnerability is 7.5:


Our Recommendations:

For the first issue we suggest users to first physically protect the environment where the device is installed in. Remember that it is the matter of seconds to insert the malicious SD and get full access to the device. Also it is recommended to check the current SD cards to make sure they are not manipulated. “etc/plcnext/plcnext_shadow.sqlite” and “etc/plcnext/plcnext_users.sqlite” databases should be checked for any unwanted account.

Based on the response we received from Phoenix Contact, moving configuration files to the internal flash will be introduced with the next release (2019.6). So, users should update the firmware as soon as the release is available.


Regarding the second issue we suggest users first update the firmware as soon as possible to version 2019.0 LTS or later and also use the latest version of PLCNEXT ENGINEER software to program the PLC. The device is not automatically updated so the users should do that by themselves. As mentioned in the change notes, please note that updating to firmware version 2019.0 LTS will reset the controller to factory default setting and any application-specific data and projects on the controller will be deleted.


Responsible Disclosure

September 13 2018: Vulnerabilities’ details sent to Phoenix Contact incident response team. Our first plan was to expose them in 2 months.


September 14 2018: First response received from Phoenix Contact. They simply mentioned they had involved the responsible team who would start verifying the vulnerabilities shortly.


October 12 2018: Second response received from Phoenix Contact. Regarding the first vulnerability they simply mentioned that with the next release of the PLCnext firmware for AXC F 2152 they would add a more clear and detailed documentation that physical access to the device must be protected and regarding second vulnerability they asked for more details to be able to trigger the vulnerability.


October 25 2018: Firmalyzer provided the following feedback. Regarding the first vulnerability we said that this means the device has no physical security which is a design flaw that cannot protect the device against malicious insiders or changes during the shipment which are out of the control of companies and that's why the vendor should consider physical access protection in its product. We also referred them to one of  the technical measures in ENISA's baseline IoT security recommendation which is:

"Ensure that the device cannot be easily disassembled and that the data storage medium is encrypted at rest and cannot be easily removed. There should be mechanisms to control device security settings, such as remotely locking or erasing contents of a device if the device has been stolen."

Moreover, we asked for their reason to store those security credentials/configurations inside an easily removable SD card without any protections.

Regarding the second vulnerability we provided more details for them to be able to trigger that.


November 09 2018: Received another response from Phoenix Contact. They could trigger the second vulnerability with the additional information. They mentioned for the attack to work it is necessary that the authenticated user actively confirms the warning regarding a certificate failure ( in our case we never got any certificate warning ). They assessed a score of 6.1 (medium) according CVSSv3 for the vulnerability:

They mentioned that they already started deep analysis to identify and fix the issue. They planned to fix it for the end of Q1/2019 and asked us to postpone the disclosure until the fix is available. According to their certified IEC 62443-4-1 process, medium scored vulnerabilities are scheduled with next regular update which are provided quarterly.

Regarding the first vulnerability they emphasized that they rely on the security of the environments the device is used in which are primarily industrial environments expected to use state-of-the-are to protect against physical access.

Their reason to store all the configurations on SD card was the regular requirement of their customers to restore system availability as quickly as possible without deep technical know how in the event of a hardware defect.

They also mentioned as an enhancement of their security concept they were discussing how to fulfill the IEC 62443-4-2 EDR 3.11 (Physical tamper resistance and detection ) requirement either with technical measurements or physical protection.


November 18 2018: Firmalyzer gave them the following feedback. Regarding vuln 2 we did not observe any warning message for the certificate failure and the only message showed in the PC WORX was "unable to connect". Also, to make the crash happen no user interaction or specific privilege is required. The only requirement is that the attacker be able to access the network that the plcnext device is connected to. We asked them to reconsider the problem as well as the vulnerability score. In our opinion the score was 7.5.

Regarding vuln 1 we explained that what they expected from industrial environments is just something ideal and what we have observed in action in a lot of them has been pretty different. Also, any state of the art protection method/product has its holes which are found out over time and it is not rational to rely on them while we can do better. We also suggested them the other solutions that while address the customers requirement, do not need the configurations be stored on the SD card.


March 04 2019: Since we did not receive any other response afterwards we sent them another message and asked for the updates. Also, mentioned our plan to disclose the issues and asked them to keep us updated with the fixes or if they have any specific plan which they want us to publish in our public report.


March 04 2019: They mentioned that they solved the issue in the current release (2019.0) and are currently preparing an advisory for that.

They also mentioned they planned to move configuration files to the internal flash which could only be introduced with the next release (2019.6).


March 20 2019: Received another message from Phoenix Contact, we were asked to recheck the issues on firmware version 2019.0 LTS and PLCNEXT ENGINEER software. They also mentioned they solved all relevant issues we found on their firmware using our firmware security analysis platform.


April 02 2019: We confirmed that the issue is fixed and shared them the date of the disclosure. For the issues we had found in their firmware they fixed some of the relevant ones but then again there were new vulnerabilities in some of them which is the reason every company should perform the firmware check regularly to be able to fix new issues.

April 08 2019: Firmalyzer disclosed the vulnerabilities and published the report.



First of all we need to clarify that our mission is not to assess the devices, report vulnerabilities and get credit out of them. Our mission is to increase the security of connected devices in the best possible way by working with different stakeholders, exchanging feedback and reflecting the results to the others.


We need to indicate that although we found those issues on the product, the overall security level of the product was quite good and even improved in the newer versions. We also found Phoenix Contact incident response team fluid. Although fixing the issues took more time than what it should have, regarding the newness of the device as well as the internal challenges that a lot of companies usually face in these situations, that was understandable for us. For this reason we decided to postpone disclosing the issues. We did not want to create another source of urgency in developers who might not be able to develop or test the products correctly and increase the chance of releasing buggy security patches that might arise another risk inside critical infrastructures where availability is the most important thing. That is one of the reasons that patches are not usually applied so fast in critical environments. So, the only result of exposing vulnerabilities that are highly dependant on vendors’ fixes but has not been patched or the patches are not supposed to be applied fast, is increasing the probability of them being hacked.


It is also worth mentioning practical lessons different stakeholders can learn which we look at it as a cyber security culture and try to spread it this way.


Vendors when designing their products, should consider the lowest possible security level about the environments their products are supposed to be use in. They also should not rely on the other security measures used or should be used in those environments. They need to broaden their security perspective to the whole supply chain as well as the cases when they try to address customers needs.


Users should not just rely on certificates or other labels. They need to assess the risks of the products especially the devices deployed in their networks from different perspectives, scrutinize the impacts and define right policies based upon. They should consider security as one of the high priority selection criteria for the products they plan to procure and look for the cyber security clauses in their SLAs with vendors. We believe cyber security is still one of those rights you need to ask for until it is given to you.


Finally, we would like to give a special thanks to LSEC for supporting our assessment.