Key takeaways
- CoAP (RFC 7252) is a REST-like protocol built for constrained IoT devices over UDP, and it ships with no security by default — NoSec is a named, legitimate configuration, not an oversight.
- RFC 8613 defines OSCORE (Object Security for Constrained RESTful Environments) specifically to close that gap.
- Two independent, differently-run scans reached almost the same number, which is the strongest kind of corroboration this guide found.
- Yes, consistently in the two most widely used open-source CoAP libraries, though these are implementation bugs rather than protocol-design flaws.
CoAP (RFC 7252) is a REST-like protocol built for constrained IoT devices over UDP, and it ships with no security by default — NoSec is a named, legitimate configuration, not an oversight. Two independent internet-wide scans, Shadowserver's in 2020 and NETSCOUT's in 2019, each found several hundred thousand exposed CoAP hosts and calculated almost the same amplification factor (around 34x), confirming CoAP's unsecured default is not a theoretical risk but a measured, ongoing source of DDoS reflection capacity and real attacks already observed in the wild.
What is CoAP, and what does "no security by default" actually mean?
CoAP is an IETF standard published by the Constrained RESTful Environments (CoRE) Working Group as RFC 7252, described in the spec's own abstract as "a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks." It gives small, often battery-powered IoT devices a REST-style interface — GET, PUT, POST, DELETE against named resources — without the overhead of a full TCP/TLS stack, running instead over UDP. That design choice is also the source of CoAP's two defining security properties: the protocol itself applies no cryptography unless an implementer deliberately configures it, and because it rides on UDP rather than a connection-oriented transport, a small request can trigger a disproportionately larger response — the mechanism DDoS amplification depends on.
What security modes does CoAP define, and why does OSCORE exist?
RFC 7252's Section 9 ("Securing CoAP") specifies DTLS as CoAP's primary security binding and defines four modes: NoSec (no security — the default unless changed), PreSharedKey (symmetric key authentication, keys distributed out of band), RawPublicKey (public-key authentication without a full certificate infrastructure), and Certificate (X.509 certificate-based authentication, the same trust model TLS uses on the web). These modes protect a CoAP exchange hop by hop, which is a real limitation in deployments that route through a proxy or protocol translator — DTLS, like TLS, terminates at each hop, so every intermediary can see (and potentially alter) the message in the clear.
RFC 8613 defines OSCORE (Object Security for Constrained RESTful Environments) specifically to close that gap. Rather than securing the transport, OSCORE applies end-to-end, object-level protection directly to the CoAP request/response content using CBOR Object Signing and Encryption (COSE), so the payload stays protected across however many proxies or protocol translations sit between endpoints. OSCORE and DTLS are complementary, not competing: a device can run OSCORE for end-to-end application-layer protection while still running DTLS hop by hop, or use OSCORE alone in deployments where DTLS isn't practical — OMA's LwM2M device-management protocol, for example, added OSCORE as an option precisely to support proxy operations its original pure-DTLS model couldn't handle.
How exposed are real CoAP devices, and how bad is the amplification risk?
Two independent, differently-run scans reached almost the same number, which is the strongest kind of corroboration this guide found. The Shadowserver Foundation's internet-wide IPv4 scan, dated 21 June 2020, sent a 21-byte CoAP discovery request to UDP port 5683 across routable address space and found 464,159 exposed hosts, concentrated in the Philippines, China and Russia (roughly 93% of the total between them), with an average response of 569 bytes — an amplification factor Shadowserver describes as "around 34." NETSCOUT's ASERT team, publishing in January 2019, found 388,344 exposed devices (81% in China) using a similar method, with a 21-byte request producing a 720-byte average response — again, an amplification factor of 34 — and reported observing real DDoS attacks already using CoAP reflection beginning in mid-January 2019.
| Source | Date | Exposed hosts found | Amplification factor |
|---|---|---|---|
| Shadowserver Foundation | 21 Jun 2020 | 464,159 | ~34x |
| NETSCOUT ASERT | 31 Jan 2019 | 388,344 | ~34x |
Shadowserver has since turned this into a standing, continuously updated "Accessible CoAP Report" distributed to national CSIRTs — this is not a one-off finding but a tracked, ongoing exposure. The report also flags a second risk beyond DDoS: some exposed CoAP services leak information directly to anyone who queries them, including in some cases credentials to other services such as Wi-Fi networks.
Have real vulnerabilities been found in CoAP implementations?
Yes, consistently in the two most widely used open-source CoAP libraries, though these are implementation bugs rather than protocol-design flaws. libcoap has had multiple CVEs in 2024-2025, including CVE-2024-0962 (a stack-based buffer overflow parsing OSCORE configuration) and CVE-2025-34468 (CVSS v3.1 9.8), a stack-based buffer overflow in address resolution where "attacker-controlled hostname data is copied into a fixed 256-byte stack buffer without proper bounds checking" — a remote crash and potential remote-code-execution risk depending on the build's mitigations. A cluster of 2025 libcoap CVEs also covers NULL-pointer-dereference denial-of-service bugs in its OpenSSL/DTLS integration. Eclipse Californium, the Java CoAP implementation, has its own history including CVE-2022-39368 (a DTLS handshake failure that leaks throttling-counter state, enabling resource-exhaustion DoS) and CVE-2021-34433 (a certificate-based DTLS handshake that could succeed without verifying the client's signature in certain configurations). None of these are fixed by turning on DTLS or OSCORE correctly — they are bugs in the code parsing CoAP and DTLS messages, which is exactly why patching the library version matters independently of which security mode a device uses.
What should a device maker or integrator check first?
Confirm which security mode is actually configured, not just supported. NoSec is a legitimate protocol mode, which is precisely why it shows up in production by accident — many libraries default to it unless a developer explicitly switches to PreSharedKey, RawPublicKey, Certificate, or adds OSCORE. Firewall UDP/5683 if any device is reachable from the public internetCoAP was designed for constrained local or operator networks, not open exposure — Shadowserver's hundreds of thousands of exposed hosts are the direct, measured cost of skipping this. Patch the specific CoAP library in your firmwarelibcoap and Eclipse Californium have each had multiple CVEs through 2024-2025; a correctly configured DTLS/OSCORE setup does not protect against a buffer overflow in the library parsing the message before security is even applied. If using OMA LwM2M for device management, check its security-mode configuration explicitly— LwM2M inherits CoAP's four DTLS modes directly, and only newer LwM2M versions add OSCORE as a separate, independently configured layer. Re-verify after any firmware updatethat the configured security mode and library version weren't silently reset to a less secure default.
A passive capture of a device's network traffic is a practical way to confirm which CoAP security mode is actually in use and whether UDP/5683 is reachable from outside the intended network, without waiting for a scan like Shadowserver's to find it first: SoftWSP's device/firmware security review flags unauthenticated or internet-exposed constrained-protocol traffic as part of its network behavior analysis, with an engineer reviewing every finding and the AI-assisted report citing the specific traffic each finding is based on — see Device & Firmware Security.
This guide draws on RFC 7252 and RFC 8613 fetched directly from the IETF RFC Editor, the Shadowserver Foundation's and NETSCOUT ASERT's published internet-wide CoAP exposure research, and vulnerability records for libcoap and Eclipse Californium from VulnCheck and public CVE sources. No CISA ICS-advisory (ICSA-prefixed) naming CoAP directly was found for 2023-2026; the one CISA-relayed CoAP finding identified (a 2020 Cisco IoT Field Network Director advisory) predates that window and is cited for historical context. This guide is general information, not a substitute for a current exposure scan of your own deployment or a CVE search against your exact CoAP library version.
Sources
- IETF RFC 7252: The Constrained Application Protocol (CoAP) — Constrained RESTful Environments (CoRE) Working Group
- IETF RFC 8613: Object Security for Constrained RESTful Environments (OSCORE)
- Shadowserver Foundation: Accessible CoAP Report — scanning for exposed Constrained Application Protocol services
- NETSCOUT ASERT: "CoAP Attacks in the Wild" (31 January 2019)
- VulnCheck: CVE-2025-34468 — libcoap stack-based buffer overflow in address resolution
- Cisco Security Advisory cisco-sa-iot-coap-dos-WTBu6YTq: IoT Field Network Director CoAP DoS (CVE-2020-3162)
Frequently asked questions
What is CoAP, and does it include security by default?
The Constrained Application Protocol (CoAP) is an IETF standard, RFC 7252, published by the Constrained RESTful Environments (CoRE) Working Group as "a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks." It gives small, battery-powered or low-bandwidth IoT devices a REST-like way to expose GET/PUT/POST/DELETE-style resources, deliberately over UDP rather than TCP to avoid the overhead of a full connection-oriented stack. By default, CoAP runs with no security at all — the spec calls this the NoSec mode. Security is an optional add-on, typically DTLS, that an implementer has to deliberately turn on; nothing in CoAP's base request/response exchange requires it, which is the same "secure by default is not the default" pattern seen across other lightweight IoT protocols.
What security modes does CoAP actually define, and what is OSCORE?
RFC 7252's Section 9 ("Securing CoAP") defines DTLS as CoAP's primary security binding, with four security modes an implementation can choose: NoSec (no security applied at all), PreSharedKey (authentication via symmetric keys shared out of band), RawPublicKey (public-key authentication without a full certificate chain), and Certificate (full X.509 certificate-based authentication, the same model as TLS on the web). The problem DTLS alone doesn't solve is that CoAP deployments commonly route through proxies and protocol translators, and DTLS — like TLS — has to be terminated at each hop, meaning every proxy in the path can read and potentially modify the message. RFC 8613 defines OSCORE (Object Security for Constrained RESTful Environments) to close that gap: it applies end-to-end, object-level encryption and integrity protection to the CoAP request/response payload itself, independent of how many proxies or protocol translations sit in between, using CBOR Object Signing and Encryption (COSE). OSCORE and DTLS are not mutually exclusive — a device can run both, layering end-to-end object security on top of hop-by-hop transport security, or run OSCORE alone where DTLS isn't practical.
How big is CoAP's amplification/DDoS exposure, and how many devices are affected?
Large enough that it has its own name in DDoS research, and two independent measurements converge on nearly the same number. The Shadowserver Foundation's internet-wide IPv4 scan (dated 21 June 2020) found 464,159 exposed CoAP hosts responding to a 21-byte discovery request on UDP port 5683, concentrated in the Philippines, China and Russia (roughly 93% of exposures combined), with an average response size of 569 bytes — an amplification factor Shadowserver put at "around 34." NETSCOUT's ASERT research team, publishing in January 2019, independently found 388,344 exposed CoAP devices (81% in China) and calculated the same 34x amplification factor from a 21-byte request producing a 720-byte average response, and documented real-world DDoS attacks already using CoAP reflection as of mid-January 2019. Shadowserver has since turned this into a continuing daily "Accessible CoAP Report" distributed to national CSIRTs, meaning the exposure is tracked as an ongoing condition, not a one-time finding. Beyond DDoS amplification, Shadowserver's report also flags that many exposed CoAP services leak information directly — including, in some cases, credentials to other services such as Wi-Fi networks.
What should a device maker or integrator using CoAP check first?
Confirm which security mode is actually configured on every CoAP endpoint — NoSec should not be the deployed configuration for any device reachable from an untrusted network, and the default in many libraries is exactly that unless explicitly changed. If devices are reachable from the public internet at all, firewall UDP/5683 to only the hosts that genuinely need it; CoAP was designed for constrained local and operator networks, not open internet exposure, and Shadowserver's hundreds of thousands of exposed hosts are the direct, measurable cost of skipping that step. Patch the specific CoAP library your firmware uses — libcoap and Eclipse Californium have each had multiple CVEs in 2024-2025, including stack-based buffer overflows and DTLS-handshake denial-of-service bugs, none of which are fixed by configuring DTLS correctly, since they are implementation bugs in the library parsing CoAP messages, not gaps in the protocol's security design. If the deployment uses OMA LwM2M for device management (which commonly carries CoAP as its transport), check which of LwM2M's own security modes is configured, since LwM2M inherits CoAP's NoSec/PreSharedKey/RawPublicKey/Certificate options directly and newer LwM2M versions add OSCORE as an additional, separately-configured layer.
In this cluster
