How to report
Our secure online intake form, the single channel for vulnerability reports.
Acknowledgement
Automated confirmation with a Tracking ID immediately on submission.
Who handles it
A named contact from the Universal Robots product security team.
Cost to you
Reporting is free. We do not operate a paid bug bounty programme.
Our commitment to you
Universal Robots is part of Teradyne, and vulnerability reports are handled by the Teradyne Product Security Incident Response Team (PSIRT) together with the UR engineering organisation, under a single Coordinated Vulnerability Disclosure (CVD) process. When you report a vulnerability to us in good faith, we commit to the following.
We will respond
Every report receives an automated acknowledgement with a Tracking ID. A member of our Product Security team then reviews it and follows up with you directly.
We will keep you informed
Once we have assessed your report, we will tell you whether we have reproduced the issue, how we have rated it, and what we intend to do about it.
We will not pursue you
If you follow the rules of engagement below, we will treat your research as authorised and will not initiate legal action or a law enforcement referral against you. See Safe harbour.
We will credit you
Where you would like it, and where a public advisory is issued, we are glad to credit you by name or handle. You may also ask to remain anonymous.
What is in scope
Security vulnerabilities in Universal Robots products and the software that runs on and alongside them. Examples include:
✔ UR cobots: the e-Series (UR3e, UR5e, UR10e, UR16e), the CB3-Series (UR3, UR5, UR10), and UR20 and UR30.
✔ PolyScope: the robot operating software, its web and pendant interfaces, its network services, and the underlying Linux system as we ship it.
✔ Robot arm, Control Box and Teach Pendant: firmware, bootloaders, onboard interfaces, exposed ports and services, and debug or service interfaces.
✔ Interfaces and protocols we implement: the primary, secondary and real time client interfaces, RTDE, Dashboard Server, XML-RPC, Modbus, PROFINET, EtherNet/IP, OPC UA, and remote access or remote control features.
✔ URCaps and the UR software ecosystem: the URCap platform and SDK, URSim, our simulation and development tooling, and URCaps published by Universal Robots. For a third party URCap, please also contact its publisher.
✔ UR operated internet facing services: our websites, the UR+ platform, customer and partner portals, the myUR portal, and download and update infrastructure.
✔ Update and supply chain integrity: software update mechanisms, signing and verification, and any way to get unauthorised code onto a robot.
These are examples, not a complete list. Our portfolio changes over time, so if your finding affects a Universal Robots product that is not named here, please submit it anyway and name the product in the form. We will route it to the right team.
What is out of scope
The following are generally not accepted. We may still review a report in this list if you can demonstrate concrete security impact, so if you are in doubt, submit it and tell us why it matters.
✕ Raw output from an automated scanner with no demonstrated exploitability or impact.
✕ Missing HTTP security headers, cookie flags, TLS configuration preferences, or SPF/DKIM/DMARC findings with no demonstrated impact.
✕ Behaviour that is documented and intended, or that requires a setting the operator has deliberately enabled, unless you can show it is exploitable in a default or reasonably expected configuration.
✕ Attacks that require the attacker to already have physical possession of a robot they are free to dismantle, with no path to remote or in-cell exploitation.
✕ Denial of service, volumetric, load or stress testing of any kind.
✕ Social engineering, phishing, or physical intrusion against employees, distributors, customers, offices or facilities.
✕ Vulnerabilities in third party end effectors, accessories, PLCs, integrator code or services we do not control. Report those to the relevant vendor, and tell us if a UR product is affected as a result.
✕ Products and software releases that have reached end of support, unless the issue also affects a supported release.
✕ Reports that consist only of a version number matched against a public CVE list, with no analysis of whether the affected code path is reachable in our product.
Safety first: rules of engagement
A cobot is industrial machinery. Careless testing can seriously injure someone.
Test only on a robot that is in a secured, unoccupied test cell that you control, with no person inside the robot’s reach, and never on a robot that is installed in a production line or in any application in productive use.
Do not attempt to influence, bypass, disable or measure the response of the functional safety system: safety rated stop functions, emergency stop, protective stop, safety limits, safety I/O or safety configuration. If your research leads you to believe you have found a way to affect a safety function, stop immediately, leave the robot powered down, and report it to us at once through the form. We treat those reports as our highest priority.
- Test only on equipment you own, or for which you have the documented, explicit permission of the owner. Never test on a customer’s or an integrator’s robot.
- Keep test robots on an isolated network segment, physically fenced or guarded, with no payload attached that could cause harm if the robot moves unexpectedly.
- Stay within scope. Do not pivot to other systems, networks or accounts.
- Use only the minimum access needed to demonstrate the issue. Stop as soon as you have proven it, and do not attempt to escalate further.
- Do not access, copy, modify or destroy data that is not yours. If you encounter personal data, customer data or credentials, stop immediately, do not retain a copy, and tell us in your report.
- Do not degrade, interrupt or damage any service, system or piece of equipment.
- Report the issue to us promptly after discovery and give us a reasonable opportunity to remediate before disclosing it publicly. Keep the details confidential between you and Teradyne until we have jointly agreed that it is appropriate to publish. Do not use your findings, or the fact of your access, to demand payment. Reports submitted with a payment demand attached are handled as extortion, not research.
- Keep the details confidential between you and us until we have jointly agreed that it is appropriate to publish.
- Do not use your findings, or the fact of your access, to demand payment. Reports submitted with a payment demand attached are handled as extortion, not research.
Safe harbour
If you make a good faith effort to comply with this policy during your research, we will consider your activity authorised. We will not initiate or support legal action against you, or refer you to law enforcement, in connection with research conducted in accordance with this policy. If a third party brings legal action against you for research that complied with this policy, we will make that compliance known.
This policy does not give you permission to act on any network, system or robot belonging to a third party, including our customers, distributors and integrators, and it does not waive any obligation you have under applicable law. If you are unsure whether something you plan to do is permitted, ask us first through the form before you do it.
What to include in your report
The intake form walks you through six short sections. The more precise you are, the faster we can reproduce the issue and route it to the engineers who own the affected code. Please have the following ready.
1. About you
Your name or handle, and an email address we can reply to. An organisation name is optional, and so is a PGP public key if you would like our follow-up encrypted.
2. Affected product
The robot model or software affected, the exact PolyScope or firmware version, the Control Box generation, and the interface, port or URL where you found the issue. This is what determines which engineering team receives your report.
3. The vulnerability
The vulnerability class, a CVE identifier if one already exists, and a technical description of the flaw: the vulnerable component, the root cause, and the conditions under which it triggers.
4. Proof and reproduction
Numbered, self-contained steps that let an engineer reproduce the issue on a clean robot or URSim instance, plus any proof of concept request, payload, script or URScript involved.
5. Impact
What an attacker gains, and be explicit if it includes influencing robot motion or a safety function. Also what they need first: network position, a valid account, physical access to the cell, a specific race condition.
6. Exposure and disclosure
Whether you have seen the issue being exploited, whether any part of it is already public, any disclosure deadline you are working to, and anything else we should know.
Attachments
You can attach supporting evidence: screenshots, logs, packet captures, crash dumps, proof of concept code, or URScript. The form accepts .txt, .py, .js, .html, .pdf, .png, .jpg, .jpeg, .gif, .pcap, .cap, .zip, .tar and .gz files. Every attachment is scanned for malware on arrival. Please redact any third party personal data before you upload, and never include live customer data.
What happens after you submit
If this is not a product vulnerability
Please use the right channel so your issue reaches the right people. This process is only for suspected security vulnerabilities.
- A robot is behaving unexpectedly or unsafely and it is not a security issue: stop using it and contact your Universal Robots distributor or support partner immediately.
- A non-security software bug, or you need help with a product: contact your distributor, or use the UR support channels on this website.
- A commercial, sales, partner or UR+ enquiry: use the contact options elsewhere on this website.
- You believe one of your own robots has been compromised: disconnect it from the network, stop using it, and contact your distributor or support partner immediately, telling them you believe it is a security incident.
- A phishing email, or a website impersonating Universal Robots: report it through the form and select information disclosure or security misconfiguration. Do not interact with the message further.
Universal Robots is a Teradyne company. If your finding affects another Teradyne brand, whether Mobile Industrial Robots, LitePoint, or Teradyne test systems, you can submit it through the same form and it will be routed to the right team.
By submitting a report you confirm that you have read and will follow this policy, and you agree that we may use the information you provide to investigate and remediate the issue, and to notify affected customers, distributors, partners and regulators as required. Your report is handled confidentially by our Product Security team.
We do not operate a paid bug bounty programme and do not offer monetary rewards for vulnerability reports.
Universal Robots Coordinated Vulnerability Disclosure policy. Effective August 26, 2026. We may update this policy; the version published here at the time you begin your research is the one that applies.
