[hansott]

No description provided.

[aikido-pr-checks]

🟡 Medium - Startup now leaves cloud firewall controls uninitialized for up to 60 seconds

When the Aikido API is slow or unreachable as the instrumented application starts, the background thread waits up to 30 seconds for the startup event and then up to another 30 seconds for blocked lists before scheduling the remaining work. The application is already instrumented and serving requests during these synchronous calls, while the local configuration starts with no cloud-provided lists or endpoints, so requests can pass IP, user-agent, and endpoint controls for up to roughly 60 seconds instead of the previous roughly 20-second window.

Suggested change

	private static final int API_TIMEOUT = 30; // 30 seconds
	private static final int API_TIMEOUT = 10; // 10 seconds

_{More info - Reply on this comment to give feedback or ignore the issue.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[aikido-pr-checks]

🟡 Medium - 60-second event timeout lets stalled reporting exhaust the attack queue

When the event endpoint accepts a connection but stalls, an attacker can keep generating detected attacks while the sole queue consumer waits up to 60 seconds on each POST. The queue is unbounded and producers continue accepting events, so sustained attack traffic can retain enough event payloads to exhaust the agent heap and degrade the instrumented application; the previous 10-second timeout drained six times faster.

Suggested change

	private static final int EVENTS_API_TIMEOUT = 60; // POST events
	private static final int EVENTS_API_TIMEOUT = 10; // POST events

_{More info - Reply on this comment to give feedback or ignore the issue.}