2025-06-05 Thu

• #AWS

  • Redis is to AWS/Elasticache with AWS/Valkey as ElasticSearch is to OpenSearch - What is Valkey

• #IDE

  • JetBrains/Writerside

• Security

  • #Filed
    • 1Password/Dev/op/run

• AI Coding

  • #Filed
    • Person/Simon Willison/GitHub/files-to-prompt
    • CursorAI/v/1/0
    • Claude/Code/How To/Set Up Github MCP with 1Password GH token and mise
  • #Updated
    • GitHub/MCP/How To/Set up in Cursor with 1Password GH token

  • #Security

    • InvariantLabsAI/Blog/25/05/GitHub MCP Exploited: Accessing private repositories via MCP

      • • My Notes

          • For security reasons, it should be obvious that one shouldn't mix the permission to write to a public repository with the permission to read from a private repository when using GitHub Fine-Grained Personal Access Tokens, and from that perspective this vulnerability's example feels like a contrived example.
            • In my opinion, personal access token hygiene dictates that:
              • engineers should create a new fine-grained personal access token for each project
              • each fine-grained personal access token should never mix writing to a public and a private repository.
            • That said, many developers will, out of laziness or ignorance, not realize that the scope of the PAT is the keyring of keys given over to an AI agent, so this is a worthwhile disclosure.
          • But in my opinion, the most interesting part of this vulnerability is something not highlighted by the example in this disclosure - a random github issue on some random github project could taint the behavior of an otherwise trusted agent. This is more serious; it means that if the agent is working on library XYZ and queries library XYZ's github issues to inquire about an error, an attacker could in theory inject malicious code into the private repository via the AI agent using MCP.