Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-40624: Critical unauthenticated RCE in AVer PTC cameras
Critical CVSS (9.8) reachable over network.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-40624 |
| CVSS score | 9.8 |
| Attack vector | Network |
| Auth required | None |
| Patch status | Fixed version not confirmed publicly during research |
TL;DR - CVE-2026-40624 is a critical reported unauthenticated RCE in AVer PTC cameras. - Affects PTC500S, PTC115, PTC500+, and PTC115+; public reporting suggests all versions. - No confirmed KEV listing or verified public PoC, but internet-exposed devices should be treated as urgent.
Technical deep dive: what is known and what is still unknown
The best-supported technical description available is improper input validation leading to remote unauthenticated arbitrary code execution. Some public write-ups additionally characterize the issue as a file and directory exposure vulnerability that can lead to code execution. That may be accurate, but because the original detailed advisory text was not fully verifiable from the sources collected, defenders should treat that extra classification as tentative rather than settled fact.
That uncertainty matters operationally. If the flaw is truly tied to path handling or file exposure, web logs and URI anomalies become especially important. If it is a broader input validation bug in a CGI or configuration endpoint, exploit attempts may look more like crafted POST requests to admin functions. In other words, defenders should not anchor too narrowly on one payload shape. Hunt for anomalous management-plane access broadly until the vendor or additional primary sources clarify the vulnerable endpoint and exploit mechanics.
The most important unknowns remain: - the exact vulnerable version range - the exact fixed version number - the precise vulnerable endpoint or service - whether public exploit code exists outside currently visible sources - whether any threat activity has been observed but not yet reflected in KEV
In the absence of those details, the safest stance is straightforward: treat the named models as potentially vulnerable, reduce network exposure, collect surrounding telemetry, and verify model-specific firmware status directly with the vendor.
Technical Notes
A minimal validation checklist for practitioners:
[ ] Inventory all AVer PTC500S, PTC115, PTC500+, and PTC115+ devices
[ ] Record firmware version on each device
[ ] Confirm whether web admin is exposed to the internet
[ ] Restrict access to admin subnets only
[ ] Enable or collect adjacent network logging
[ ] Check AVer support pages for a firmware release tied to CVE-2026-40624
[ ] Document compensating controls where patch status is unknown
What happened and why defenders should care
CVE-2026-40624 is a critical vulnerability affecting several AVer PTZ camera products: PTC500S, PTC115, PTC500+, and PTC115+. Public references consistently describe the issue as improper input validation that may allow remote, unauthenticated arbitrary code execution. The reported severity is CVSS 9.8 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which fits a worst-case profile for exposed edge devices: network reachable, no credentials needed, and high impact across confidentiality, integrity, and availability.
For defenders, the important point is not whether every technical detail has been fully disclosed yet. It is that a camera appliance class that often sits outside normal endpoint controls may be vulnerable to remote takeover. In many environments, PTZ cameras are reachable from management VLANs, AV control networks, conferencing platforms, or even the public internet for remote production workflows. That makes this issue operationally significant even without confirmed mass exploitation.
A complicating factor is that some vendor and NVD details were not fully retrievable during research. The NVD API reportedly returned 503 errors, and the CVE record itself appears only partially populated. Because of that, some fields remain unconfirmed. Where the data is unknown, defenders should assume the safer posture: if you operate one of the listed models, treat it as potentially exposed until you verify firmware, access controls, and vendor guidance.
Affected products and versions
Public references consistently name the following affected products:
| Product | Affected versions | Fixed version |
|---|---|---|
| AVer PTC500S | Public reporting suggests all versions; vendor-confirmed range not verified during research | Unknown / not publicly confirmed |
| AVer PTC115 | Public reporting suggests all versions; vendor-confirmed range not verified during research | Unknown / not publicly confirmed |
| AVer PTC500+ | Public reporting suggests all versions; vendor-confirmed range not verified during research | Unknown / not publicly confirmed |
| AVer PTC115+ | Public reporting suggests all versions; vendor-confirmed range not verified during research | Unknown / not publicly confirmed |
The versioning question is the biggest unresolved item. Available public reporting indicates “all versions” of the named products may be affected. However, the exact vulnerable version ranges were not conclusively established from a primary vendor security advisory during research. I also found a historical AVer firmware release-note PDF covering these models and referencing FW version V.65 dated 2022-11-30, but that document alone does not prove whether V.65 is vulnerable or fixed for this CVE.
Because the fixed version number is not publicly confirmed in the materials available here, defenders should avoid making assumptions such as “we are safe because we are on V.65” or “newer than 2022 means fixed.” Instead, inventory these devices, identify the exact currently installed firmware, and compare it against AVer’s official support or security guidance for the specific model. In the absence of a confirmed fixed version, restrict exposure first and patch second once vendor confirmation is obtained.
Exploitation status and practical risk
At the time of this writing, exploitation in the wild is not confirmed from the sources available here. Specifically, CISA KEV does not currently list CVE-2026-40624, which means there is no KEV-based confirmation of active exploitation. That is useful, but limited: KEV non-inclusion is not evidence that exploitation is impossible or absent. It only means CISA has not listed it as a known exploited vulnerability.
Likewise, a public proof of concept has not been verified from the materials reviewed here. That does not reduce urgency as much as some teams might hope. High-severity unauthenticated RCE bugs in embedded devices are frequently reproducible by experienced researchers or adversaries even when a PoC has not been posted publicly. If the vulnerable interface is reachable over HTTP/HTTPS or another exposed management plane, exploitation timelines can be short once technical details circulate.
The practical risk depends heavily on deployment. A camera isolated on a tightly controlled management segment with source-IP restrictions presents a different risk profile than a camera directly exposed to the internet or bridged into a flat corporate LAN. Still, because this is a reported remote unauthenticated issue, organizations should prioritize discovery of exposed devices and control plane isolation immediately, even before a fixed firmware version is confirmed.
Technical Notes
A few facts are clear enough to drive triage:
- Confirmed in the wild: Unknown; not confirmed from reviewed sources
- Public PoC: Unknown; not verified
- CISA KEV: No
- Defender assumption in absence of data: treat internet-reachable devices as high risk and potentially exploitable
Bottom line
CVE-2026-40624 should be treated as a serious infrastructure risk for organizations running affected AVer PTZ cameras. Even though exploitation in the wild is not confirmed and a public PoC is not verified from the sources reviewed, the reported vulnerability profile is severe enough to justify immediate segmentation, exposure review, and vendor firmware verification.
If you run AVer PTC500S, PTC115, PTC500+, or PTC115+, assume potential exposure until proven otherwise. The exact affected version range is publicly reported as all versions, but that has not been conclusively vendor-verified here, and the fixed version number remains unknown from accessible primary sources. That uncertainty is exactly why defenders should act now on controls they can verify: isolate the devices, log access around them, and confirm remediation against official AVer guidance as soon as it is available.
For further information on related vulnerabilities, check out our articles on CVE-2026-11450 and CVE-2026-45131.
How to identify exposure in your environment
Start with asset inventory, not vulnerability scans alone. PTZ cameras are often missed by endpoint tools and can sit under facilities, AV, or conferencing teams rather than central IT. Build a list of all AVer PTC500S, PTC115, PTC500+, and PTC115+ devices, their IP addresses, their firmware versions, and whether their management interfaces are reachable from user networks or the internet. If you cannot answer those questions quickly, that itself is the first operational gap to close.
Next, review inbound access paths. These devices may be reachable through direct NAT, reverse proxies, site-to-site VPNs, conferencing control systems, or jump hosts. Even if they are not public, access from large internal subnets can still be a problem because unauthenticated RCE can be abused after initial compromise elsewhere. The right question is not just “is it internet exposed?” but also “which systems can talk to its admin surface, and why?”
Because the vulnerable component details are not fully public in the sources reviewed, detection must be behavior-based. Focus on abnormal access to camera web interfaces, suspicious requests to file or directory handling paths, unexplained configuration changes, and outbound traffic from the camera to previously unseen destinations. If your environment lacks direct logging from the device, use firewall, proxy, IDS, and switch telemetry around it.
Technical Notes
Use these checks as starting points. They are not a signature for exploitation of this CVE specifically, but they are concrete detection opportunities for suspicious management-plane activity against these devices.
Example log pattern to hunt in reverse proxy or web logs
<camera_ip> - - [19/Jun/2026:10:14:22 +0000] "GET /../../../../etc/passwd HTTP/1.1" 400 153 "-" "curl/8.5.0"
<camera_ip> - - [19/Jun/2026:10:14:31 +0000] "POST /cgi-bin/ HTTP/1.1" 200 512 "-" "python-requests/2.32.0"
<camera_ip> - - [19/Jun/2026:10:14:35 +0000] "GET /system/config HTTP/1.1" 200 2048 "-" "Mozilla/5.0"
Example Suricata-style network rule for suspicious traversal or direct admin probing
alert http any any -> $HOME_NET any (
msg:"Possible AVer camera management path traversal or probing";
flow:to_server,established;
http.uri;
pcre:"/(\..\/|%2e%2e%2f|cgi-bin|system\/config)/Ui";
classtype:web-application-attack;
sid:4062401;
rev:1;
)
Example Splunk query for suspicious requests to camera IPs
index=proxy OR index=firewall
(dest_ip IN ("10.10.20.15","10.10.20.16","10.10.20.17"))
(method=GET OR method=POST)
(uri_path="*../*" OR uri_path="*cgi-bin*" OR uri_path="*config*" OR user_agent="*curl*" OR user_agent="*python-requests*")
| stats count min(_time) as firstSeen max(_time) as lastSeen by src_ip, dest_ip, method, uri_path, status, user_agent
| sort - count
If you do not have device logs, collect at least: - firewall accept logs to camera IPs - reverse proxy logs, if any - NetFlow or Zeek records for camera subnets - DHCP, MAC vendor, and switch-port mappings for physical location and ownership
Mitigation and patching guidance
The preferred mitigation is to upgrade to the vendor-fixed firmware version. The problem is that the specific fixed version number has not been publicly confirmed in the source set used here. Public reporting suggests firmware remediation exists or is expected, but without a verified advisory tying a version to CVE-2026-40624, it would be irresponsible to name one. Therefore, the immediate action is twofold: reduce exposure now and verify firmware directly from AVer support resources for each model.
If these cameras are internet reachable, remove that exposure first. Place them behind a VPN or jump host, restrict management access to dedicated admin source IPs, and segment them from general user networks. If remote administration is not essential, block inbound access to web management interfaces entirely. Also consider outbound restrictions: a compromised camera should not be able to make arbitrary egress connections to the internet or internal sensitive systems.
For environments with change-control constraints, a temporary workaround posture is still useful. Disable unnecessary services, rotate any credentials associated with device administration even though the issue is reportedly unauthenticated, and monitor closely for config changes or reboots. If a device cannot be isolated and no verified fix is yet available, risk owners should consider temporary replacement or disconnection for high-sensitivity locations.
Technical Notes
Check reachability from an admin workstation
curl -k -I https://CAMERA_IP/
nmap -sV -Pn CAMERA_IP
Example firewall restriction using Linux nftables on a management gateway
sudo nft add rule inet filter forward ip daddr CAMERA_IP tcp dport {80,443} ip saddr != ADMIN_SUBNET drop
Example temporary ACL on a Cisco-style device
ip access-list extended CAMERA-MGMT
permit tcp ADMIN_SUBNET WILDCARD host CAMERA_IP eq 443
permit tcp ADMIN_SUBNET WILDCARD host CAMERA_IP eq 80
deny tcp any host CAMERA_IP eq 443
deny tcp any host CAMERA_IP eq 80
permit ip any any
What to do about firmware
1. Log into the AVer support portal for the exact model.
2. Download the latest firmware and release notes for PTC500S, PTC115, PTC500+, or PTC115+.
3. Confirm whether the release notes or advisory explicitly mention CVE-2026-40624.
4. Stage the update on a non-production device if possible.
5. Apply the firmware using the vendor's documented process.
Because the exact upgrade command depends on the device UI and AVer distribution method, a universal CLI upgrade command could not be verified here. If your deployment uses centralized AV management, document the actual upgrade steps internally and tie them to model-specific evidence from AVer before rollout.
References and source confidence
Primary references reviewed include the CVE.org record, the GitHub Advisory Database entry, an AVer support page, an AVer firmware release-note PDF, and a CISA ICS advisory URL associated in public reporting. During research, some authoritative sources were partially inaccessible or incomplete, including reported 503 responses from the NVD API and difficulty retrieving the full advisory body from other sources. That is why this article distinguishes carefully between verified facts and unresolved items.
The strongest verified facts are the CVE ID, affected product family names, the reported CVSS 9.8 vector, the high-level description of unauthenticated remote code execution, and the lack of current KEV listing. The weakest points are the exact affected version range and exact fixed version. Practitioners should therefore use this write-up as a triage and response guide, then complete patch validation directly against AVer’s current support and security materials before closing remediation.
References - CVE.org: https://www.cve.org/CVERecord?id=CVE-2026-40624 - GitHub Advisory Database: https://github.com/advisories/GHSA-pg6m-mhv8-fpmp - AVer PTC115 support page: https://www.aver.com/helpcenter-faq/professional-ptz-camera/ptc115 - AVer firmware release notes (V.65): https://www.averusa.com/pro-av/downloads/firmware/TR_V65_ReleaseNote_20221130.pdf - CISA ICS advisory URL associated in reporting: https://www.cisa.gov/news-events/ics-advisories/icsa-26-169-01