Report a security vulnerability
Our autonomous mobile robots move through busy warehouses, factories and hospitals alongside people. Keeping them secure is part of keeping them safe. If you have found a security vulnerability in a MiR robot, in MiR Robot Software, or in MiR Fleet, we want to hear from you.
Secure intake form. No account required.
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 MiR product security team.
Cost to you
Reporting is free. We do not operate a paid bug bounty programme.
Our commitment to you
Mobile Industrial Robots is part of Teradyne, and vulnerability reports are handled by the Teradyne Product Security Incident Response Team (PSIRT) together with the MiR 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.
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 Mobile Industrial Robots products and the software that runs on and alongside them. Examples include:
✔ MiR AMRs: the light duty models (MiR100, MiR200, MiR250), the heavy duty models (MiR500, MiR600, MiR1000, MiR1350), and the MiR1200 Pallet Jack.
✔ MiR Robot Software: the onboard robot software, its web interface and REST API, its network services, and the underlying Linux system as we ship it.
✔ MiR Fleet: the fleet management software, its web interface and API, and the way it authenticates, authorises and communicates with robots.
✔ Robot hardware and onboard systems: onboard controllers, firmware, bootloaders, exposed ports and services, wireless interfaces, and debug or service interfaces.
✔ Interfaces, integrations and accessories: the REST and WebSocket APIs, MQTT and other messaging interfaces, ROS interfaces we expose, mission and map handling, charging stations, and MiR top modules and shelf carriers.
✔ MiR operated internet facing services: our websites, customer and distributor portals, 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 or onto a fleet controller.
These are examples, not a complete list. Our portfolio changes over time, so if your finding affects a MiR 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-facility 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 top modules, accessories, WMS or ERP systems, integrator code, or services we do not control. Report those to the relevant vendor, and tell us if a MiR 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
An AMR is a moving industrial vehicle. Careless testing can seriously injure someone.
Test only on a robot in a secured, cordoned test area that you control, with no pedestrians, vehicles or obstructions in its path, and never on a robot that is operating in a live warehouse, production, logistics or healthcare environment.
Do not attempt to influence, bypass, disable or measure the response of the functional safety system: safety laser scanners, protective stops, emergency stop, speed and zone limits, or safety configuration.
If your research leads you to believe you have found a way to affect a safety function, to move a robot without authorisation, or to alter its perception of its surroundings, 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 or fleet.
Keep test robots on an isolated network segment, in a physically cordoned area, with no payload or load carrier that could cause harm if the robot moves unexpectedly.
Stay within scope. Do not pivot to other systems, networks or accounts, and do not interact with robots or fleet controllers that are not yours.
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. Maps, mission histories and camera or scanner data can reveal a customer's site layout and operations, so if you encounter data of this kind, or personal 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 MiR Robot Software or MiR Fleet version, and the interface, port, API endpoint 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 MiR Fleet installation, plus any proof of concept request, payload, script or mission definition involved.
5. Impact
What an attacker gains, and be explicit if it includes moving a robot, altering a mission or map, or affecting a safety function. Also what they need first: network position, a valid account, physical access to the site, a 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, or proof of concept code. 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, site maps or operational recordings belonging to a customer.
What happens after you submit
1. You get a Tracking ID
As soon as your report is received you get an automated confirmation email with a Tracking ID. Quote it in any follow-up so we can find your report instantly.
2. We triage and route it
Your report is assessed for severity and regulatory significance, then routed to the MiR product security and engineering team, where a named contact picks it up. Anything touching a safety function or unauthorised robot motion is escalated immediately.
3. We validate and rate it
Our engineers attempt to reproduce the issue and assign a severity using CVSS. We will come back to you if we need more detail, and we will tell you the outcome of the assessment, including if we conclude it is not a vulnerability, and why.
4. We remediate
Confirmed issues are tracked to a fix in our engineering systems. Because our products are safety related industrial vehicles, a fix must be validated and qualified before it ships, which influences timelines. We will keep you updated on progress.
5. We disclose together
Where appropriate we publish an advisory and, if applicable, request a CVE identifier. We coordinate timing with you and credit you as you prefer. If we are required to notify a regulator or a national CSIRT, we will do so and let you know.
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 MiR distributor or support partner immediately.
A non-security software bug, or you need help with a product: contact your distributor, or use the MiR support channels on this website.
A commercial, sales, distributor or partner enquiry: use the contact options elsewhere on this website.
You believe one of your own robots or fleets has been compromised: disconnect it from the network, stop operations, and contact your distributor or support partner immediately, telling them you believe it is a security incident.
A phishing email, or a website impersonating Mobile Industrial Robots: report it through the form and select information disclosure or security misconfiguration. Do not interact with the message further.
Mobile Industrial Robots is a Teradyne company. If your finding affects another Teradyne brand, whether Universal Robots, LitePoint, or Teradyne test systems, you can submit it through the same form and it will be routed to the right team.
Ready to report?
The form takes about ten minutes if you have your reproduction steps and evidence to hand. It is submitted over an encrypted connection directly to our Product Security 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.
Mobile Industrial 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.