security/openvpn-legacy: read-only user can stop a running VPN

Open Beginner friendly
  • Is something wrong?
#5,887 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@besendorf is already working on this.

Since Nov 5, 2026.

  • #5888 by @besendorf — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
authentication, security

Research direction

Start by reading /vpn_openvpn_server.php and /vpn_openvpn_client.php, focusing on the POST delete and toggle paths and the order of openvpn_delete() and write_config(). Reproduce the read-only user's denied write behavior and check how each page handles it. Done when read-only POSTs cause no runtime or configuration changes and the UI reports the denial instead of success.

Written by the indexing model from the issue text.

Description

incomplete

Summary

os-openvpn-legacy permits a WebGUI user with the OpenVPN Servers page privilege and user-config-readonly to stop a running legacy OpenVPN server. The delete action calls openvpn_delete() before write_config(). The latter rejects the configuration write, but the runtime process has already been stopped. The client page has the same call order. Both pages also ignore the failed write when applying toggle actions.

Severity and affected versions

Proposed severity: Moderate (VPN availability impact requiring an authenticated user with the relevant page privilege).

Verified on OPNsense Community 26.7.8_2 with os-openvpn-legacy 1.0_2. The current plugin source at commit 7c8cc9544b9cbe36d428aece439565167b6841c5 contains the same paths. Earlier versions have not been tested; the last unaffected version is unknown. The affected GUI page is /vpn_openvpn_server.php; the analogous client page is /vpn_openvpn_client.php.

Reproduction and observed result

In an isolated VM, a disposable legacy OpenVPN server was running. A new non-root account had exactly page-openvpn-server, page-system-login-logout, and user-config-readonly. That account could access the legacy server page and sent a CSRF-valid act=del&id=0 POST. The page returned HTTP 200 and {"status":"ok"}. The server remained in the saved configuration, while /api/core/service/search changed from running: 1 to running: 0. The test server and account were removed afterward.

The client delete and both toggle paths are source-confirmed but were not separately reproduced.

Suggested fix

Reject POST requests from user-config-readonly users before any runtime or configuration changes in both legacy pages. Handle the denied write explicitly so the UI does not report a successful deletion.

AI assistance disclosure

OpenAI GPT-6 assisted with source review, drafting, and the local reproduction script. The behavior and disposable VM result were checked against OPNsense 26.7.8_2 and os-openvpn-legacy 1.0_2.

Dominant language
PHP
Stars
1.2k
Forks
905
Avg merge
4d 16h
Merged PRs (30d)
21

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from opnsense/plugins

All issues in opnsense/plugins

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.