Add Akita Share Token (■AKITA) on Base

[wenakita]

Add Akita Share Token on Base

Token details:

• Name: Akita Share Token
• Symbol: ■AKITA
• Contract: 0x44710150A469DE368Abc82F05e6217086Be84626
• Chain: Base (chainId 8453)
• Decimals: 18
• Type: BASE / ERC20

Project:
Share token for the Akita creator vault on 4626.fun (Base).

Website: https://4626.fun
Explorer: https://basescan.org/token/0x44710150A469DE368Abc82F05e6217086Be84626
Metadata: https://4626.fun/tokens/akita-share-token.json
Logo (canonical): https://4626.fun/tokens/akita-share-token.png

Checklist:

• Token contract is verified / live on Basescan
• Logo is 256x256 PNG under 100KB
• info.json contains required fields
• Folder name matches EIP-55 checksummed contract address

Made with Cursor

[wenakita]

Updated logo.png to the curated Akita portrait (256×256 PNG, under 100KB).

[semgrep-code-uniswap]

Semgrep identified a blocking 🔴 issue in your code:

User-controlled github.event.inputs.use-size-only is interpolated directly into a run: step and used in eval, allowing command injection via workflow dispatch input.

More details about this

The run: step passes ${{ github.event.inputs.use-size-only }} directly into a conditional that modifies SYNC_OPTIONS, which is then used in an eval statement. This creates a command injection vulnerability.

Exploit scenario:

1. An attacker opens a workflow dispatch request (which triggers on workflow_dispatch events) and provides a malicious value for the use-size-only input parameter
2. The attacker sets use-size-only to: true"; malicious_command; echo "
3. When the conditional evaluates if [ "${{ github.event.inputs.use-size-only }}" == "true" ], it becomes: if [ "true"; malicious_command; echo "" == "true" ]
4. The shell parses this as three commands: [ "true", malicious_command, and echo ""
5. The malicious_command executes with full access to the runner environment, including AWS_S3_BUCKET secret
6. The attacker can now read secrets, exfiltrate code, or modify the repository

The real danger is that SYNC_OPTIONS is later used in eval, which interprets shell metacharacters. Even if the attacker can't break out of the conditional, they could inject options into SYNC_OPTIONS that cause unintended behavior.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	run: |
	SYNC_OPTIONS="--follow-symlinks --delete --exclude '*' --include 'dapps/*' --include 'blockchains/*'"
	if [ "${{ github.event.inputs.use-size-only }}" == "true" ]; then
	SYNC_OPTIONS="$SYNC_OPTIONS --size-only"
	fi
	eval "aws s3 sync . s3://$AWS_S3_BUCKET $SYNC_OPTIONS"
	run: |
	SYNC_OPTIONS="--follow-symlinks --delete --exclude '*' --include 'dapps/*' --include 'blockchains/*'"
	if [ "$USE_SIZE_ONLY" = "true" ]; then
	SYNC_OPTIONS="$SYNC_OPTIONS --size-only"
	fi
	eval "aws s3 sync . s3://$AWS_S3_BUCKET $SYNC_OPTIONS"
	env:
	AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
	USE_SIZE_ONLY: ${{ github.event.inputs.use-size-only }}

View step-by-step instructions

1. Move the untrusted workflow input out of the run: script and into the step env: block, for example by adding USE_SIZE_ONLY: ${{ github.event.inputs.use-size-only }}.
2. Replace the direct GitHub expression inside the shell script with the environment variable, changing the condition to if [ "$USE_SIZE_ONLY" = "true" ]; then.
3. Keep the environment variable quoted everywhere you read it in the shell script, because "$USE_SIZE_ONLY" prevents shell metacharacters in the input from being interpreted as code.
4. Leave AWS_S3_BUCKET in env: as it is, and keep shell variable references quoted where possible, for example aws s3 sync . "s3://$AWS_S3_BUCKET" ....
5. Remove GitHub ${{ ... }} interpolation from this run: block entirely so the script only reads shell variables provided through env:.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-shell-injection.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[wenakita]

Superseded: #92 targeted abandoned remine-1 ShareOFT 0xcCC10Ec9282F66dd4e344DF52F5D670D10Fd4626 (Base only) and carried a large unrelated commit history.

Canonical remine-2 ■AKITA is 0xe7e44b29E966E3f77EF491fef0F663573Fd74626 (CREATE2 parity) plus Solana mint A6HB5FWRjknVuMXpuwupr6QjZpsRSS98nBb1DW9dAZsH.

Closing in favor of the clean multi-chain PR opened from wenakita:add-akita-share-token-remine2.

[wenakita]

Closing in favor of remine-2 multi-chain PR (see comment above).

[wenakita]

New PR: #94