7fab2e51ff
 The critical vulnerability involved exposing the debugpy debugger server on 0.0.0.0:5678 (all network interfaces) when certain environment variables were set, which allowed unauthenticated remote code execution. This was fixed by changing the debugpy --listen argument from 0.0.0.0:5678 to 127.0.0.1:5678, ensuring the debug server is bound only to localhost and is not externally accessible. All other code and logic were left unchanged. <details> <summary>More Details</summary> | Type | Identifier | Message | Severity | Link | |------|------------|---------|----------|------| | <pre>Application</pre> | <pre>CWE-489, CWE-284</pre> | When both ENVIRONMENT=dev/local and DEBUG=true are set, the script launches `debugpy` bound to 0.0.0.0:5678 and waits for a client to attach. `debugpy` shells allow full, arbitrary code execution inside the running container/process. If the container or host network is exposed—even inadvertently—an attacker can connect to this port and gain RCE. Because only environment variables gate this behavior, a mis-configuration, leaked compose file, or SSRF that sets these variables could unintentionally expose the debugger in production.<br>Impact: Remote Code Execution, full compromise of the application and underlying data.<br>Severity is elevated as the issue provides unauthenticated code-level access to the live service. | <pre>critical</pre> | [Link](https://console.pensar.dev/cognee/projects/cognee/a3838758-8ac3-4f46-8d34-035abb845e91) | </details> Co-authored-by: pensarapp[bot] <182705637+pensarapp[bot]@users.noreply.github.com>
46 lines
No EOL
1.9 KiB
Bash
Executable file
46 lines
No EOL
1.9 KiB
Bash
Executable file
#!/bin/bash
|
|
|
|
set -e # Exit on error
|
|
echo "Debug mode: $DEBUG"
|
|
echo "Environment: $ENVIRONMENT"
|
|
|
|
# Run Alembic migrations with proper error handling.
|
|
# Note on UserAlreadyExists error handling:
|
|
# During database migrations, we attempt to create a default user. If this user
|
|
# already exists (e.g., from a previous deployment or migration), it's not a
|
|
# critical error and shouldn't prevent the application from starting. This is
|
|
# different from other migration errors which could indicate database schema
|
|
# inconsistencies and should cause the startup to fail. This check allows for
|
|
# smooth redeployments and container restarts while maintaining data integrity.
|
|
echo "Running database migrations..."
|
|
|
|
MIGRATION_OUTPUT=$(alembic upgrade head)
|
|
MIGRATION_EXIT_CODE=$?
|
|
|
|
if [[ $MIGRATION_EXIT_CODE -ne 0 ]]; then
|
|
if [[ "$MIGRATION_OUTPUT" == *"UserAlreadyExists"* ]] || [[ "$MIGRATION_OUTPUT" == *"User default_user@example.com already exists"* ]]; then
|
|
echo "Warning: Default user already exists, continuing startup..."
|
|
else
|
|
echo "Migration failed with unexpected error."
|
|
exit 1
|
|
fi
|
|
fi
|
|
|
|
echo "Database migrations done."
|
|
|
|
echo "Starting server..."
|
|
|
|
# Add startup delay to ensure DB is ready
|
|
sleep 2
|
|
|
|
# Modified Gunicorn startup with error handling
|
|
if [ "$ENVIRONMENT" = "dev" ] || [ "$ENVIRONMENT" = "local" ]; then
|
|
if [ "$DEBUG" = "true" ]; then
|
|
echo "Waiting for the debugger to attach..."
|
|
debugpy --wait-for-client --listen 127.0.0.1:5678 -m gunicorn -w 3 -k uvicorn.workers.UvicornWorker -t 30000 --bind=0.0.0.0:8000 --log-level debug --reload cognee.api.client:app
|
|
else
|
|
gunicorn -w 3 -k uvicorn.workers.UvicornWorker -t 30000 --bind=0.0.0.0:8000 --log-level debug --reload cognee.api.client:app
|
|
fi
|
|
else
|
|
gunicorn -w 3 -k uvicorn.workers.UvicornWorker -t 30000 --bind=0.0.0.0:8000 --log-level error cognee.api.client:app
|
|
fi |