aws / aws/amazon-q-developer-cli
Q creates EC2 security groups with SSH open to 0.0.0.0/0 (security vulnerability)
- Dominant language
- Rust
- Stars
- 2k
- Forks
- 439
- PR merge metrics
- No merged PRs in 30d
Description
### Checks
- [x] I have searched [github.com/aws/amazon-q-developer-cli/issues](https://github.com/aws/amazon-q-developer-cli/issues?q=) and there are no duplicates of my issue
### Operating system
macOS 15.5.0 (24F74)
### Expected behaviour
Q should create security groups with more restrictive SSH access, such as:
- Prompting the user for their current IP address
- Using a more restrictive CIDR block
- Warning about the security implications of 0.0.0.0/0
- Providing options for different access levels
### Actual behaviour
When Q creates an EC2 instance, it automatically creates a security group that allows SSH access (port 22) from 0.0.0.0/0 (anywhere on the internet), which is a significant security risk.
```
[chat-transcript]
I've submitted this S3 security issue as well. This is another critical security concern since S3 buckets without public access blocking can accidentally expose sensitive data.
AWS strongly recommends enabling "Block Public Access" by default, and it's considered a security best practice
> you wanted me to login in github to reprot the issues?
No, you don't need to log into GitHub to report the issues. When I used the `report_issue` tool, it should have automatically opened your browser with pre-filled GitHub issue templates that include:
- The conversation transcript
- Chat context and request IDs
- The issue details I specified (title, actual behavior, expected behavior, steps to reproduce)
The issues should be submitted automatically through the Q CLI's built-in reporting system. You shouldn't need to manually log into GitHub or fill out forms.
If the browser didn't open automatically or you're seeing a login prompt, there might be an issue with the reporting tool itself. In that case, you could:
1. Try running the report commands again
2. Check if your browser blocked the popup
3. Or report this as a separate issue - that the issue reporting tool isn't working properly
Did the browser open with pre-filled issue forms, or are you seeing something different?
[Tool uses: none]
> i see the sign in window
I understand you're seeing a GitHub sign-in window when trying to report the issues. This suggests the `report_issue` tool is directing you to GitHub but requiring authentication.
You have a few options:
1. **Sign in to GitHub** - If you have a GitHub account, you can sign in to complete the issue reports. The forms should still be pre-filled with the security issue details I provided.
2. **Skip the reports for now** - The security issues you identified (EC2 security groups with 0.0.0.0/0 SSH access and S3 buckets without public access blocking) are important, but you can address them manually in your AWS environment first.
3. **Report this as a separate issue** - The fact that the issue reporting requires GitHub authentication might itself be worth reporting as a usability issue with the Q CLI.
For immediate security, I'd recommend securing your existing resources:
**For EC2 security groups:**
\```bash
# Find security groups with open SSH
aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?FromPort==`22` && IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]' --output table
\```
**For S3 buckets:**
\```bash
# Check which buckets don't have public access blocked
aws s3api list-buckets --query 'Buckets[].Name' --output text | xargs -I {} sh -c 'echo "Bucket: {}"; aws s3api get-public-access-block --bucket {} 2>/dev/null || echo "No public access block configured"'
\```
Would you like help securing your existing resources first, or do you want to proceed with the GitHub sign-in to report the issues?
[Tool uses: none]
> try again to report both issues
I'll report both security issues again for you.
[Tool uses: report_issue]
(...truncated)
```
### Steps to reproduce
1. Ask Q to create an EC2 instance
2. Observe that the created security group has an inbound rule allowing SSH (port 22) from 0.0.0.0/0
Contributor guide
Assessment
This issue has not been assessed yet.