Security

Known vulnerabilities

Apache NuttX RTOS vulnerabilities are labelled with CVE (Common Vulnerabilities and Exposures) identifiers. List of known, responsibly disclosed, and fixed vulnerabilities are publicly available online at CVE.ORG and at the bottom of this page in the NuttX CVEs section.

CVE IDs are unique identifiers given to security vulnerabilities. The Apache Security Team is a CVE Numbering Authority (CNA) covering all Apache projects and is the only group able to allocate IDs to Apache Software Foundation project issues.

Not security vulnerabilities

Apache NuttX RTOS is highly portable to over 15 different CPU architectures, including microcontrollers with as tiny memory resources as single kilobytes of RAM/Flash memory. Putting additional checks outside a generic nature would dramatically impact final firmware performance and size. Function parameters and incoming data validation rests on the custom application/firmware developer.

Special care should be taken when handling:

  • syscalls.

  • pointers (always set to NULL before and after use).

  • structures (always initialize with {0} before use).

  • user controllable data (type and size).

  • network data.

  • dynamically allocated buffers.

Note

If you find a generic problem in existing code base that may impact Confidentiality, Integrity, or Availability (i.e. information leak, denial of service, remote code execution) and is not your own custom application specific, please send us a security report.

Security Issues Handling

Security related issues are handled in compliance with The Apache Security Team Guide and Apache Committers Security Guide. Please read these documents carefully before submitting and/or handling a security vulnerabilities. Below is an extract of the information.

Warning

Do not enter details of security vulnerabilities in a project’s public bug tracker, issues, or pull requests. Do not make information about the vulnerability public until it is formally announced at the end of this process. Messages associated with any commits should not make any reference to the security nature of the commit.

  1. Report:

  1. Please report potential security vulnerabilities over email to security@nuttx.apache.org before disclosing them in any public form. This enables responsible disclosure by providing a fix for everyone impacted before details are made public. Messages sent to our security@ address are automatically copied to security@apache.org.

  2. Please send one plain-text, unencrypted, email for each vulnerability you are reporting. We may ask you to resubmit your report if you send it as an image, movie, HTML, or PDF attachment when you could as easily describe it with plain text.

  3. Do not enter details of security vulnerabilities in a project’s public bug tracker, issues, or pull requests. Do not make information about the vulnerability public until it is formally announced at the end of this process. Messages associated with any commits should not make any reference to the security nature of the commit.

  4. Security fixes are usually part of the standard release cycle, but for urgent cases special patch releases may be created to address the issue. In order to keep this process smooth please provide us with as much details as possible. Reproducible examples, proof-of-concept code, but most importantly fix patches are more than welcome.

  5. There are problems that we are well aware of, and have been reported to us many times, but we do not classify as a security vulnerability, see Not security vulnerabilities for details. Please consider reporting them as Issue or Pull Request on GitHub instead.

  6. The project team sends an e-mail to the original reporter to acknowledge the report, with a copy to the relevant security mailing list.

  1. Investigation:

  1. The project team investigates the report and either rejects or accepts it.

  2. Project team members may share information about the vulnerability with domain experts (including colleagues at their employer) at the discretion of the project’s security team, providing that they make clear that the information is not for public disclosure.

  3. If the project team rejects the report, the team writes to the reporter to explain why, with a copy to the relevant security mailing list.

  4. If the project team accepts the report, the team writes to the reporter to let them know that they have accepted the report and that they are working on a fix or validating fix provided by the reporter. CVE ID is requested where problem details are reported upon resolution.

  1. Resolution:

  1. The project team agrees on a fix on their private list.

  2. The project team requests a CVE (Common Vulnerabilities and Exposures) ID from the internal portal, https://cveprocess.apache.org. Apache Security Team can help determine if a report requires multiple CVE IDs or if multiple reports should be merged under a single CVE ID. CVE ID can be shared with the reporter.

  3. The project team documents the details of the vulnerability and the fix on the internal portal. The portal generates draft announcement texts. For an example of an announcement see Tomcat’s announcement of CVE-2008-2370. The level of detail to include in the report is a matter of judgement. Generally, reports should contain enough information to enable people to assess the risk the vulnerability poses for their own system, and no more. Announcements do not normally include steps to reproduce the vulnerability.

  4. Optionally CVE can be set into the REVIEW state to request a review from the Apache Security team. Discussion is possible using the “comment” feature which also sends the comments to the private mailing list(s).

  5. The project team provides the reporter with a copy of the fix and the draft vulnerability announcement for comment.

  6. The project team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is unresponsive in a reasonable timeframe this should not block the project team from moving to the next steps, particularly if an issue is of high severity/impact.

  7. The project team commits the fix without making any reference that the commit relates to a security vulnerability.

  8. The project team creates a release that includes the fix.

  1. Public announcement:

  1. After (or at the same time as) the release announcement, the project team announces the vulnerability and the fix. CVE status is set to READY in the internal portal, that is also used to send emails. This is the first point that any information regarding the vulnerability is made public. The vulnerability announcement should be sent to the following destinations:

    1. the same destinations as the release announcement.

    2. the vulnerability reporter.

    3. the project’s security list (or security@apache.org if the project does not have a dedicated security list).

    4. oss-security@lists.openwall.com (subscription not required).

  2. The project team updates the project’s security pages.

NuttX CVEs

CVE-2025-48769

Use After Free vulnerability was discovered in fs/vfs/fs_rename code of the Apache NuttX RTOS, that due recursive implementation and single buffer use by two different pointer variables allowed arbitrary user provided size buffer reallocation and write to the previously freed heap chunk, that in specific cases could cause unintended virtual filesystem rename/move operation results. This issue affects Apache NuttX RTOS: from 7.20 before 12.11.0. Users of virtual filesystem based services with write access especially when exposed over the network (i.e. FTP) are affected and recommended to upgrade to version 12.11.0 that fixes the issue.

CVE-2025-48768

Release of Invalid Pointer or Reference vulnerability was discovered in fs/inode/fs_inoderemove code of the Apache NuttX RTOS that allowed root filesystem inode removal leading to a debug assert trigger (that is disabled by default), NULL pointer dereference (handled differently depending on the target architecture), or in general, a Denial of Service. This issue affects Apache NuttX RTOS: from 10.0.0 before 12.10.0. Users of filesystem based services with write access that were exposed over the network (i.e. FTP) are affected and recommended to upgrade to version 12.10.0 that fixes the issue.

CVE-2025-47869

Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability was discovered in Apache NuttX RTOS apps/exapmles/xmlrpc application. In this example application device stats structure that stored remotely provided parameters had hardcoded buffer size which could lead to buffer overflow. Structure members buffers were updated to valid size of CONFIG_XMLRPC_STRINGSIZE+1. This issue affects Apache NuttX RTOS users that may have used or base their code on example application as presented in releases from 6.22 before 12.9.0. Users of XMLRPC in Apache NuttX RTOS are advised to review their code for this pattern and update buffer sizes as presented in the version of the example in release 12.9.0.

CVE-2025-47868

Out-of-bounds Write resulting in possible Heap-based Buffer Overflow vulnerability was discovered in tools/bdf-converter font conversion utility that is part of Apache NuttX RTOS repository. This standalone program is optional and neither part of NuttX RTOS nor Applications runtime, but active bdf-converter users may be affected when this tool is exposed to external provided user data data (i.e. publicly available automation). This issue affects Apache NuttX: from 6.9 before 12.9.0. Users are recommended to upgrade to version 12.9.0, which fixes the issue.

CVE-2025-35003

Improper Restriction of Operations within the Bounds of a Memory Buffer and Stack-based Buffer Overflow vulnerabilities were discovered in Apache NuttX RTOS Bluetooth Stack (HCI and UART components) that may result in system crash, denial of service, or arbitrary code execution, after receiving maliciously crafted packets. NuttX’s Bluetooth HCI/UART stack users are advised to upgrade to version 12.9.0, which fixes the identified implementation issues.

CVE-2021-34125

An issue discovered in Yuneec Mantis Q and PX4-Autopilot v1.11.3 and below allow attacker to gain access to sensitive information via various nuttx commands.

CVE-2021-26461

Apache Nuttx Versions prior to 10.1.0 are vulnerable to integer wrap-around in functions malloc, realloc and memalign. This improper memory assignment can lead to arbitrary memory allocation, resulting in unexpected behavior such as a crash or a remote code injection/execution.

CVE-2020-17529

Out-of-bounds Write vulnerability in TCP Stack of Apache NuttX (incubating) versions up to and including 9.1.0 and 10.0.0 allows attacker to corrupt memory by supplying and invalid fragmentation offset value specified in the IP header. This is only impacts builds with both CONFIG_EXPERIMENTAL and CONFIG_NET_TCP_REASSEMBLY build flags enabled.

CVE-2020-17528

Out-of-bounds Write vulnerability in TCP stack of Apache NuttX (incubating) versions up to and including 9.1.0 and 10.0.0 allows attacker to corrupt memory by supplying arbitrary urgent data pointer offsets within TCP packets including beyond the length of the packet.

CVE-2020-1939

The Apache NuttX (Incubating) project provides an optional separate “apps” repository which contains various optional components and example programs. One of these, ftpd, had a NULL pointer dereference bug. The NuttX RTOS itself is not affected. Users of the optional apps repository are affected only if they have enabled ftpd. Versions 6.15 to 8.2 are affected.

CVE-2018-20578

An issue was discovered in NuttX before 7.27. The function netlib_parsehttpurl() in apps/netutils/netlib/netlib_parsehttpurl.c mishandles URLs longer than hostlen bytes (in the webclient, this is set by default to 40), leading to an Infinite Loop. The attack vector is the Location header of an HTTP 3xx response.