BUGS.md

# Table of Contents

- [lurk-lab](https://github.com/zksecurity/zkbugs/tree/main/dataset/lurk-lab)
    - [bellperson/lurk-lab/lurk-rs/inference_Multicase_number_of_defaults_not_enforced](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/lurk-rs/inference_Multicase_number_of_defaults_not_enforced)
    - [bellperson/lurk-lab/lurk-rs/inference_Under_constrained_outputs_in_reduce_sym](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/lurk-rs/inference_Under_constrained_outputs_in_reduce_sym)
    - [bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_to_0_value_not_enforced](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_to_0_value_not_enforced)
    - [bellperson/lurk-lab/lurk-rs/inference_Vectors_not_constrained_to_be_of_the_same_size](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/lurk-rs/inference_Vectors_not_constrained_to_be_of_the_same_size)
    - [bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_toaccumulator_1_initial_value_not_enforced](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_toaccumulator_1_initial_value_not_enforced)
    - [bellperson/lurk-lab/neptune/inference_Zero_padding_not_enforced](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/lurk-lab/neptune/inference_Zero_padding_not_enforced)
- [filecoin-project](https://github.com/zksecurity/zkbugs/tree/main/dataset/filecoin-project)
    - [bellperson/filecoin-project/rust-fil-proofs/trapdoor_Add_missing_public_input_for_replica_id](https://github.com/zksecurity/zkbugs/tree/main/dataset/bellperson/filecoin-project/rust-fil-proofs/trapdoor_Add_missing_public_input_for_replica_id)
- [Consensys](https://github.com/zksecurity/zkbugs/tree/main/dataset/Consensys)
    - [gnark/Consensys/gnark/Unsoundness_in_variable_comparison__non_unique_binary_decomposition](https://github.com/zksecurity/zkbugs/tree/main/dataset/gnark/Consensys/gnark/Unsoundness_in_variable_comparison__non_unique_binary_decomposition)
- [scroll-tech](https://github.com/zksecurity/zkbugs/tree/main/dataset/scroll-tech)
    - [halo2/scroll-tech/poseidon-circuit/zellic_mpt_only_being_true_leads_to_overconstrained_circuits](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/poseidon-circuit/zellic_mpt_only_being_true_leads_to_overconstrained_circuits)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_Nondeterministic_execution_of_ReturnDataCopyGadget_and_ErrorReturnDataOutOfBoundGadget](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_Nondeterministic_execution_of_ReturnDataCopyGadget_and_ErrorReturnDataOutOfBoundGadget)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Highest_tx_id_must_be_equal_to_cum_num_txs_in_Tx_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Highest_tx_id_must_be_equal_to_cum_num_txs_in_Tx_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_check_in_the_initialization_on_the_state_machine_in_RLP_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_check_in_the_initialization_on_the_state_machine_in_RLP_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_constraint_for_the_first_tx_id_in_Tx_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_constraint_for_the_first_tx_id_in_Tx_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_The_invalid_creation_error_handling_circuit_is_unconstrained](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_The_invalid_creation_error_handling_circuit_is_unconstrained)
    - [halo2/scroll-tech/zkevm-circuits/zellic_ChainId_is_not_mapped_to_its_corresponding_RLP_Tag_in_Tx_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_ChainId_is_not_mapped_to_its_corresponding_RLP_Tag_in_Tx_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_do_not_emit!_constraints](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_do_not_emit!_constraints)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_Underconstrained_warm_status_on_CALL_opcodes_allows_gas_cost_forgery](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_Underconstrained_warm_status_on_CALL_opcodes_allows_gas_cost_forgery)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_ModGadget_is_underconstrained_and_allows_incorrect_MULMOD_operations_to_be_proven](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_ModGadget_is_underconstrained_and_allows_incorrect_MULMOD_operations_to_be_proven)
    - [halo2/scroll-tech/zkevm-circuits/zellic_The_CallDataRLC_value_in_the_fixed_assignments_is_not_validated_against_the_actual_calldata_in_Tx_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_The_CallDataRLC_value_in_the_fixed_assignments_is_not_validated_against_the_actual_calldata_in_Tx_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_The_first_row_of_each_Tx_in_the_calldata_section_is_undercon__strained_in_Tx_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_The_first_row_of_each_Tx_in_the_calldata_section_is_undercon__strained_in_Tx_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_in_MulAdd_chip](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_in_MulAdd_chip)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_Incorrect_state_transitions_can_be_proven_for_any_chunk_by_manipulating_padding_flags](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_Incorrect_state_transitions_can_be_proven_for_any_chunk_by_manipulating_padding_flags)
    - [halo2/scroll-tech/zkevm-circuits/zellic_padding_shift_is_underconstrained_in_the_bytecode_circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_padding_shift_is_underconstrained_in_the_bytecode_circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Equality_between_tag_value_and_the_final_tag_value_acc_not_checked](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Equality_between_tag_value_and_the_final_tag_value_acc_not_checked)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Block_number_constraints_are_incorrect_in_PI_circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Block_number_constraints_are_incorrect_in_PI_circuit)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_The_RlpU64Gadget_is_underconstrained_when_is_lt_128_is_false](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_The_RlpU64Gadget_is_underconstrained_when_is_lt_128_is_false)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Transition_to_new_RLP_instance_in_the_state_machine_is_un__derconstrained_in_RLP_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Transition_to_new_RLP_instance_in_the_state_machine_is_un__derconstrained_in_RLP_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Non_trivial_rotation_incorrectly_handled_in_ComparatorChip](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Non_trivial_rotation_incorrectly_handled_in_ComparatorChip)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Multiple_RLP_encodings_share_the_same_RLC_value](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Multiple_RLP_encodings_share_the_same_RLC_value)
    - [halo2/scroll-tech/zkevm-circuits/zellic_The_sv_address_is_not_constrained_to_be_equal_throughout_a_single_transaction](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_The_sv_address_is_not_constrained_to_be_equal_throughout_a_single_transaction)
    - [halo2/scroll-tech/zkevm-circuits/zellic_The_state_machine_is_not_constrained_to_end_at_End](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_The_state_machine_is_not_constrained_to_end_at_End)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_check_for_byte_values_in_RLP_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_check_for_byte_values_in_RLP_Circuit)
    - [halo2/scroll-tech/zkevm-circuits/zellic_ExpCircuit_has_a_under_constrained_exponentiation_algorithm_](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_ExpCircuit_has_a_under_constrained_exponentiation_algorithm_)
    - [halo2/scroll-tech/zkevm-circuits/trailofbits_The_CREATE_and_CREATE2_opcodes_can_be_called_within_a_static_context](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/trailofbits_The_CREATE_and_CREATE2_opcodes_can_be_called_within_a_static_context)
    - [halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_for_the_LtChip](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_for_the_LtChip)
    - [halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_for_new_account_in_configure_balance](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_for_new_account_in_configure_balance)
    - [halo2/scroll-tech/mpt-circuit/zellic_Incorrect_constraints_in_configure_nonce](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/zellic_Incorrect_constraints_in_configure_nonce)
    - [halo2/scroll-tech/mpt-circuit/zellic_The_OneHot_encoding_gadget_has_incorrect_constraints](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/zellic_The_OneHot_encoding_gadget_has_incorrect_constraints)
    - [halo2/scroll-tech/mpt-circuit/trailofbits_The_NonceChanged_configuration_circuit_does_not_constrain_the_new_value_nonce_value](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/trailofbits_The_NonceChanged_configuration_circuit_does_not_constrain_the_new_value_nonce_value)
    - [halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_in_configure_empty_storage](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_in_configure_empty_storage)
    - [halo2/scroll-tech/mpt-circuit/zellic_Missing_range_check_for_address_values_in_MPT_Circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/zellic_Missing_range_check_for_address_values_in_MPT_Circuit)
    - [halo2/scroll-tech/mpt-circuit/trailofbits_The_OneHot_primitive_allows_more_than_one_value_at_once](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/scroll-tech/mpt-circuit/trailofbits_The_OneHot_primitive_allows_more_than_one_value_at_once)
- [summa-dev](https://github.com/zksecurity/zkbugs/tree/main/dataset/summa-dev)
    - [halo2/summa-dev/summa-solvency/Constant_assignment_to_check_bug](https://github.com/zksecurity/zkbugs/tree/main/dataset/halo2/summa-dev/summa-solvency/Constant_assignment_to_check_bug)
- [risc0](https://github.com/zksecurity/zkbugs/tree/main/dataset/risc0)
    - [risc0/risc0/risc0/ghsa_zkvm_underconstrained_3reg_instructions](https://github.com/zksecurity/zkbugs/tree/main/dataset/risc0/risc0/risc0/ghsa_zkvm_underconstrained_3reg_instructions)
    - [risc0/risc0/risc0/ghsa_insufficient_zkvm_validation_multistep_modes](https://github.com/zksecurity/zkbugs/tree/main/dataset/risc0/risc0/risc0/ghsa_insufficient_zkvm_validation_multistep_modes)
    - [risc0/risc0/risc0/ghsa_underconstrained_division](https://github.com/zksecurity/zkbugs/tree/main/dataset/risc0/risc0/risc0/ghsa_underconstrained_division)
- [starkware-libs](https://github.com/zksecurity/zkbugs/tree/main/dataset/starkware-libs)
    - [cairo/starkware-libs/stark-perpetual/abdk_This_function_cannot_handle_the_case_when_n_risk_factor_segments_is_zero](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/starkware-libs/stark-perpetual/abdk_This_function_cannot_handle_the_case_when_n_risk_factor_segments_is_zero)
- [HerodotusDev](https://github.com/zksecurity/zkbugs/tree/main/dataset/HerodotusDev)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Function_doesnt_ensure_that_y_is_a_power_of_two](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Function_doesnt_ensure_that_y_is_a_power_of_two)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_position_is_not_range_checked](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_position_is_not_range_checked)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Missing_range_checks_for_negative_values](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Missing_range_checks_for_negative_values)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_offset_is_not_range_checked](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_offset_is_not_range_checked)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_len_is_not_range_checked](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_len_is_not_range_checked)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Implicitly_requires_value_to_fit_into_128_32_160_bits](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Implicitly_requires_value_to_fit_into_128_32_160_bits)
    - [cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_peaks_len_is_not_range_checked](https://github.com/zksecurity/zkbugs/tree/main/dataset/cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_peaks_len_is_not_range_checked)
- [0xPolygonHermez](https://github.com/zksecurity/zkbugs/tree/main/dataset/0xPolygonHermez)
    - [pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_execution_flow_hijack](https://github.com/zksecurity/zkbugs/tree/main/dataset/pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_execution_flow_hijack)
    - [pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_proving_fake_inclusion_in_the_SMT](https://github.com/zksecurity/zkbugs/tree/main/dataset/pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_proving_fake_inclusion_in_the_SMT)
- [penumbra-zone](https://github.com/zksecurity/zkbugs/tree/main/dataset/penumbra-zone)
    - [arkworks/penumbra-zone/penumbra/nccgroup_Invalid_Comparisons_on_Fixed_Point_Values_are_Accepted_by_the_Circuit_Verifier](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks/penumbra-zone/penumbra/nccgroup_Invalid_Comparisons_on_Fixed_Point_Values_are_Accepted_by_the_Circuit_Verifier)
    - [arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_addition](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_addition)
    - [arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_multiplication](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_multiplication)
    - [arkworks/penumbra-zone/penumbra/zksecurity_Double_spending_due_to_incoming_viewing_key_ivk_derivation_not_constrained](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks/penumbra-zone/penumbra/zksecurity_Double_spending_due_to_incoming_viewing_key_ivk_derivation_not_constrained)
- [arkworks-rs](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks-rs)
    - [arkworks/arkworks-rs/r1cs-std/Enforce_mul_by_inverse](https://github.com/zksecurity/zkbugs/tree/main/dataset/arkworks/arkworks-rs/r1cs-std/Enforce_mul_by_inverse)
- [openvm-org](https://github.com/zksecurity/zkbugs/tree/main/dataset/openvm-org)
    - [plonky3/openvm-org/openvm/ghsa_plonky3_fri_verifier_vulnerabilities](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/openvm-org/openvm/ghsa_plonky3_fri_verifier_vulnerabilities)
    - [plonky3/openvm-org/openvm/ghsa_auipc_pc_byte_decomposition_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/openvm-org/openvm/ghsa_auipc_pc_byte_decomposition_overflow)
- [succinctlabs](https://github.com/zksecurity/zkbugs/tree/main/dataset/succinctlabs)
    - [plonky3/succinctlabs/sp1/ghsa_insufficient_range_checks_babybear_arithmetic](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_insufficient_range_checks_babybear_arithmetic)
    - [plonky3/succinctlabs/sp1/ghsa_missing_chip_ordering_validation](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_missing_chip_ordering_validation)
    - [plonky3/succinctlabs/sp1/ghsa_allocator_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_allocator_overflow)
    - [plonky3/succinctlabs/sp1/ghsa_insufficient_observation_cumulative_sum](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_insufficient_observation_cumulative_sum)
    - [plonky3/succinctlabs/sp1/ghsa_underconstrained_is_complete_flag](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_underconstrained_is_complete_flag)
    - [plonky3/succinctlabs/sp1/ghsa_verifier_vk_root_validation](https://github.com/zksecurity/zkbugs/tree/main/dataset/plonky3/succinctlabs/sp1/ghsa_verifier_vk_root_validation)
    - [circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_including_ill-formed_bigints_in_public_key_commitment](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_including_ill-formed_bigints_in_public_key_commitment)
    - [circom/succinctlabs/telepathy-circuits/veridise_template_CoreVerifyPubkeyG1_does_not_perform_input_validation_simplified](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/veridise_template_CoreVerifyPubkeyG1_does_not_perform_input_validation_simplified)
    - [circom/succinctlabs/telepathy-circuits/veridise_zero_padding_for_sha256_in_ExpandMessageXMD_is_vulnerable_to_an_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/veridise_zero_padding_for_sha256_in_ExpandMessageXMD_is_vulnerable_to_an_overflow)
    - [circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_supplying_non-reduced_Y_values_to_G1BigIntToSignFlag](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_supplying_non-reduced_Y_values_to_G1BigIntToSignFlag)
    - [circom/succinctlabs/telepathy-circuits/trailofbits_incorrect_handling_of_point_doubling_can_allow_signature_forgery](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/trailofbits_incorrect_handling_of_point_doubling_can_allow_signature_forgery)
    - [circom/succinctlabs/telepathy-circuits/veridise_arrayxor_is_under_constrained](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/succinctlabs/telepathy-circuits/veridise_arrayxor_is_under_constrained)
- [zkopru-network](https://github.com/zksecurity/zkbugs/tree/main/dataset/zkopru-network)
    - [circom/zkopru-network/zkopru/leastauthority_previously_correct_ownership_proof_disabled_via_code_changes](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkopru-network/zkopru/leastauthority_previously_correct_ownership_proof_disabled_via_code_changes)
    - [circom/zkopru-network/zkopru/leastauthority_Circuit_Does_Not_Check_the_ERC_20_Sum_Correctly_](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkopru-network/zkopru/leastauthority_Circuit_Does_Not_Check_the_ERC_20_Sum_Correctly_)
- [worm-privacy](https://github.com/zksecurity/zkbugs/tree/main/dataset/worm-privacy)
    - [circom/worm-privacy/proof-of-burn/koukyosyumei_spend_missing_range_check](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/worm-privacy/proof-of-burn/koukyosyumei_spend_missing_range_check)
- [privacy-scaling-explorations](https://github.com/zksecurity/zkbugs/tree/main/dataset/privacy-scaling-explorations)
    - [circom/privacy-scaling-explorations/maci/hashcloak_data_are_not_fully_verified_during_state_update](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/privacy-scaling-explorations/maci/hashcloak_data_are_not_fully_verified_during_state_update)
- [tangle-network](https://github.com/zksecurity/zkbugs/tree/main/dataset/tangle-network)
    - [circom/tangle-network/protocol-solidity/veridise_incorrect_initialization_in_membership_circuits](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/tangle-network/protocol-solidity/veridise_incorrect_initialization_in_membership_circuits)
- [aptos-labs](https://github.com/zksecurity/zkbugs/tree/main/dataset/aptos-labs)
    - [circom/aptos-labs/keyless-zk-proofs/koukyosyumei_unconstrained_base64_decoded_len](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/aptos-labs/keyless-zk-proofs/koukyosyumei_unconstrained_base64_decoded_len)
- [semaphore-protocol](https://github.com/zksecurity/zkbugs/tree/main/dataset/semaphore-protocol)
    - [circom/semaphore-protocol/semaphore/veridise_no_zero_value_validation](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/semaphore-protocol/semaphore/veridise_no_zero_value_validation)
- [siv-org](https://github.com/zksecurity/zkbugs/tree/main/dataset/siv-org)
    - [circom/siv-org/verifiable-private-overrides/koukyosyumei_emitifinrange_lessthan_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/siv-org/verifiable-private-overrides/koukyosyumei_emitifinrange_lessthan_overflow)
    - [circom/siv-org/verifiable-private-overrides/koukyosyumei_extractstringfrompoint_shiftedfirstbyte_unconstrained](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/siv-org/verifiable-private-overrides/koukyosyumei_extractstringfrompoint_shiftedfirstbyte_unconstrained)
- [personaelabs](https://github.com/zksecurity/zkbugs/tree/main/dataset/personaelabs)
    - [circom/personaelabs/spartan-ecdsa/yacademy_Knowledge_of_any_member_signature_allow_to_generate_proof_of_membership](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/personaelabs/spartan-ecdsa/yacademy_Knowledge_of_any_member_signature_allow_to_generate_proof_of_membership)
    - [circom/personaelabs/spartan-ecdsa/yacademy_input_signal_s_is_not_constrained_in_eff_ecdsa_circom](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/personaelabs/spartan-ecdsa/yacademy_input_signal_s_is_not_constrained_in_eff_ecdsa_circom)
    - [circom/personaelabs/spartan-ecdsa/yacademy_under_constrained_circuits_compromising_the_soundness_of_the_system](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/personaelabs/spartan-ecdsa/yacademy_under_constrained_circuits_compromising_the_soundness_of_the_system)
- [inference-labs-inc](https://github.com/zksecurity/zkbugs/tree/main/dataset/inference-labs-inc)
    - [circom/inference-labs-inc/subnet-2-circom/koukyosyumei_clamp_comparator_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/inference-labs-inc/subnet-2-circom/koukyosyumei_clamp_comparator_overflow)
    - [circom/inference-labs-inc/subnet-2-circom/koukyosyumei_subtract_unconstrained_multiplier](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/inference-labs-inc/subnet-2-circom/koukyosyumei_subtract_unconstrained_multiplier)
- [0xbok](https://github.com/zksecurity/zkbugs/tree/main/dataset/0xbok)
    - [circom/0xbok/circom-bigint/veridise_missing_range_checks_in_bigmod](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/0xbok/circom-bigint/veridise_missing_range_checks_in_bigmod)
- [pantherfoundation](https://github.com/zksecurity/zkbugs/tree/main/dataset/pantherfoundation)
    - [circom/pantherfoundation/panther-core/veridise_zaccount_renewal_kyc_expiry_not_validated](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_zaccount_renewal_kyc_expiry_not_validated)
    - [circom/pantherfoundation/panther-core/veridise_zaccount_renewal_multiple_nullifiers_same_utxo](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_zaccount_renewal_multiple_nullifiers_same_utxo)
    - [circom/pantherfoundation/panther-core/veridise_babyjubjub_suborder_constraints_not_applied_correctly](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_babyjubjub_suborder_constraints_not_applied_correctly)
    - [circom/pantherfoundation/panther-core/veridise_zone_limits_bypass_zswapv1](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_zone_limits_bypass_zswapv1)
    - [circom/pantherfoundation/panther-core/veridise_zone_id_inclusion_prover_bypass](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_zone_id_inclusion_prover_bypass)
    - [circom/pantherfoundation/panther-core/veridise_kyt_signature_verification_fails_nonzero_hash](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_kyt_signature_verification_fails_nonzero_hash)
    - [circom/pantherfoundation/panther-core/veridise_nullifier_verification_can_be_disabled](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_nullifier_verification_can_be_disabled)
    - [circom/pantherfoundation/panther-core/veridise_bypassing_internal_transfer_limits_via_swaps](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_bypassing_internal_transfer_limits_via_swaps)
    - [circom/pantherfoundation/panther-core/veridise_fortxreward_abstracted_away_in_reward_calc](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_fortxreward_abstracted_away_in_reward_calc)
    - [circom/pantherfoundation/panther-core/veridise_data_escrow_encrypted_message_wrong_input](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_data_escrow_encrypted_message_wrong_input)
    - [circom/pantherfoundation/panther-core/veridise_blacklist_states_not_representable_in_field](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_blacklist_states_not_representable_in_field)
    - [circom/pantherfoundation/panther-core/veridise_unsafe_num2bits_254_blacklist_leaf](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/pantherfoundation/panther-core/veridise_unsafe_num2bits_254_blacklist_leaf)
- [Unirep](https://github.com/zksecurity/zkbugs/tree/main/dataset/Unirep)
    - [circom/Unirep/Unirep/veridise_missing_range_checks_on_comparison_circuits](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Unirep/Unirep/veridise_missing_range_checks_on_comparison_circuits)
    - [circom/Unirep/Unirep/veridise_underconstrained_circuit_allows_invalid_comparison](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Unirep/Unirep/veridise_underconstrained_circuit_allows_invalid_comparison)
- [Rate-Limiting-Nullifier](https://github.com/zksecurity/zkbugs/tree/main/dataset/Rate-Limiting-Nullifier)
    - [circom/Rate-Limiting-Nullifier/circom-rln/veridise_spammers_may_slash_themselves](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Rate-Limiting-Nullifier/circom-rln/veridise_spammers_may_slash_themselves)
- [darkforest-eth](https://github.com/zksecurity/zkbugs/tree/main/dataset/darkforest-eth)
    - [circom/darkforest-eth/darkforest-v0.3/daira_hopwood_darkforest_v0_3_missing_bit_length_check](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/darkforest-eth/darkforest-v0.3/daira_hopwood_darkforest_v0_3_missing_bit_length_check)
- [sismo-core](https://github.com/zksecurity/zkbugs/tree/main/dataset/sismo-core)
    - [circom/sismo-core/hydra-s2-zkps/veridise_private_information_leakage](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/sismo-core/hydra-s2-zkps/veridise_private_information_leakage)
- [banyancomputer](https://github.com/zksecurity/zkbugs/tree/main/dataset/banyancomputer)
    - [circom/banyancomputer/hot-proofs-blake3-circom/koukyosyumei_checkdepth_comparator_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/banyancomputer/hot-proofs-blake3-circom/koukyosyumei_checkdepth_comparator_overflow)
- [selfxyz](https://github.com/zksecurity/zkbugs/tree/main/dataset/selfxyz)
    - [circom/selfxyz/self/zksecurity_missing_byte_range_checks_allows_packed_data_pollution](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_missing_byte_range_checks_allows_packed_data_pollution)
    - [circom/selfxyz/self/zksecurity_missing_boolean_constraints_in_the_merkle_tree_path_leads_to_an_attacker_being_able_to_craft_a_fake_merkle_proof_for_an_arbitrary_leaf](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_missing_boolean_constraints_in_the_merkle_tree_path_leads_to_an_attacker_being_able_to_craft_a_fake_merkle_proof_for_an_arbitrary_leaf)
    - [circom/selfxyz/self/zksecurity_an_attacker_can_craft_a_fake_non_inclusion_proof_for_a_given_key_due_to_an_aliasing_bug_in_the_smt_verifier](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_an_attacker_can_craft_a_fake_non_inclusion_proof_for_a_given_key_due_to_an_aliasing_bug_in_the_smt_verifier)
    - [circom/selfxyz/self/zksecurity_second_pre_image_attacks_on_packbytesandposeidon_may_be_used_to_register_arbitrary_passports_and_dsc_certificates](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_second_pre_image_attacks_on_packbytesandposeidon_may_be_used_to_register_arbitrary_passports_and_dsc_certificates)
    - [circom/selfxyz/self/zksecurity_big_integer_zero_check_is_not_sound](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_big_integer_zero_check_is_not_sound)
    - [circom/selfxyz/self/zksecurity_the_registration_and_disclosure_circuits_lack_range_checks_for_the_input_indices](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_the_registration_and_disclosure_circuits_lack_range_checks_for_the_input_indices)
    - [circom/selfxyz/self/zksecurity_forbidden_country_check_bypass_via_packed_byte_overflow](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_forbidden_country_check_bypass_via_packed_byte_overflow)
    - [circom/selfxyz/self/zksecurity_exclusion_check_of_forbidden_countries_is_unsound_and_incomplete_due_to_incorrect_indexing](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/selfxyz/self/zksecurity_exclusion_check_of_forbidden_countries_is_unsound_and_incomplete_due_to_incorrect_indexing)
- [Moonsong-Labs](https://github.com/zksecurity/zkbugs/tree/main/dataset/Moonsong-Labs)
    - [circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_non_determinism_of_some_inputs](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_non_determinism_of_some_inputs)
    - [circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_mismatched_base64url_decoding_may_break_completeness](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_mismatched_base64url_decoding_may_break_completeness)
- [iden3](https://github.com/zksecurity/zkbugs/tree/main/dataset/iden3)
    - [circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryAdd](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryAdd)
    - [circom/iden3/circomlib/veridise_underconstrained_outputs_in_bitElementMulAny](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_outputs_in_bitElementMulAny)
    - [circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryDouble](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryDouble)
    - [circom/iden3/circomlib/veridise_decoder_accepting_bogus_output_signal](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_decoder_accepting_bogus_output_signal)
    - [circom/iden3/circomlib/veridise_underconstrained_outputs_in_windowmulfix](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_outputs_in_windowmulfix)
    - [circom/iden3/circomlib/veridise_underconstrained_outputs_in_window4](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_outputs_in_window4)
    - [circom/iden3/circomlib/veridise_underconstrained_points_in_edwards2Montgomery](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_points_in_edwards2Montgomery)
    - [circom/iden3/circomlib/kobi_gurkan_mimc_hash_assigned_but_not_constrained](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/kobi_gurkan_mimc_hash_assigned_but_not_constrained)
    - [circom/iden3/circomlib/veridise_underconstrained_points_in_montgomery2Edwards](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circomlib/veridise_underconstrained_points_in_montgomery2Edwards)
    - [circom/iden3/circuits/trailofbits_unsafe_use_of_num2bits_in_multiple_circuits](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/iden3/circuits/trailofbits_unsafe_use_of_num2bits_in_multiple_circuits)
- [reclaimprotocol](https://github.com/zksecurity/zkbugs/tree/main/dataset/reclaimprotocol)
    - [circom/reclaimprotocol/circom-chacha20/zksecurity_unsound_left_rotation](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/reclaimprotocol/circom-chacha20/zksecurity_unsound_left_rotation)
    - [circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_XOR_gadget](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_XOR_gadget)
    - [circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_Addition_Gadget](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_Addition_Gadget)
- [Arianee](https://github.com/zksecurity/zkbugs/tree/main/dataset/Arianee)
    - [circom/Arianee/arianee-sdk/veridise_ownershipproofs_could_identify_issuers](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Arianee/arianee-sdk/veridise_ownershipproofs_could_identify_issuers)
    - [circom/Arianee/arianee-sdk/veridise_creditnoteproofs_can_be_stolen](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/Arianee/arianee-sdk/veridise_creditnoteproofs_can_be_stolen)
- [rarimo](https://github.com/zksecurity/zkbugs/tree/main/dataset/rarimo)
    - [circom/rarimo/passport-zk-circuits/koukyosyumei_under_constrained_date_encoder](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/rarimo/passport-zk-circuits/koukyosyumei_under_constrained_date_encoder)
- [zkemail](https://github.com/zksecurity/zkbugs/tree/main/dataset/zkemail)
    - [circom/zkemail/zk-email-verify/matterlabs_underconstrained_fpmul_circuit](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkemail/zk-email-verify/matterlabs_underconstrained_fpmul_circuit)
    - [circom/zkemail/zk-email-verify/zksecurity_sha256_templates_return_zero_on_arbitrary_inputs](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkemail/zk-email-verify/zksecurity_sha256_templates_return_zero_on_arbitrary_inputs)
    - [circom/zkemail/zk-regex/matterlabs_fromaddrregex_allows_email_address_spoofing](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkemail/zk-regex/matterlabs_fromaddrregex_allows_email_address_spoofing)
    - [circom/zkemail/zk-regex/matterlabs_email_spoofing_via_manipulated_from_header](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkemail/zk-regex/matterlabs_email_spoofing_via_manipulated_from_header)
    - [circom/zkemail/ether-email-auth/matterlabs_emailauth_fails_with_overlapping_invitation_code_regex](https://github.com/zksecurity/zkbugs/tree/main/dataset/circom/zkemail/ether-email-auth/matterlabs_emailauth_fails_with_overlapping_invitation_code_regex)

# lurk-lab

## bellperson/lurk-lab/lurk-rs/inference_Multicase_number_of_defaults_not_enforced

### Multicase number of defaults not enforced

* Id: lurk-lab/lurk-rs/inference_Multicase_number_of_defaults_not_enforced
* Project: https://github.com/lurk-lab/lurk-rs
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: edcda9760a66088db78f64994513fa19d67caa79
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/circuits
  - Function: apply_continuation
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Multicase number of defaults not enforced
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Multicase number of defaults not enforced" refers to an issue in the 'apply_continuation()' function in Lurk's circuit logic, where it incorrectly sized the default argument for the 'multi_case' function. This misalignment resulted in some constraints not being properly enforced. The problem was rectified by supplying the correct number of arguments and adding an assertion to detect incorrect usage in the future.

#### Proposed Mitigation

The recommended fix for the bug 'Multicase number of defaults not enforced' is providing the correct number of arguments to the function and adding an assertion to detect incorrect usage in the future. This was implemented in commit edcda97.


## bellperson/lurk-lab/lurk-rs/inference_Under_constrained_outputs_in_reduce_sym

### Under-constrained outputs in reduce_sym

* Id: lurk-lab/lurk-rs/inference_Under-constrained_outputs_in_reduce_sym
* Project: https://github.com/lurk-lab/lurk-rs
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: 7236df555c2cfc7c37d290666d7d5167b3447032
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/circuits/reduce_sym.rs
  - Function: reduce_sym
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Under-constrained outputs in reduce_sym
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug S-LRK-05 'Under-constrained outputs in reduce_sym' involves the reduction circuit not sufficiently constraining symbolic-expression outputs. Though the circuit is supposed to enforce outputs to be one of ten possible results, contingent on specific conditions, the constraints were initially weak or missing. This led to intermediate complexities, making the potential outcomes unconstrained under certain conditions. Upon review and refactoring, modifications were made to improve output constraints, enhance code clarity compared to specifications, and optimize the circuit design.

#### Proposed Mitigation

The recommended fix for the bug 'Under-constrained outputs in reduce_sym' involves refactoring the function `reduce_sym` into three parts: computing all branch conditions and possible output values, assigning predicates that are true when their value should be returned, and adding constraints to enforce the outputs. This refactoring makes the code more understandable and comparable to the Rust specification while reducing the total number of constraints.


## bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_to_0_value_not_enforced

### Soundness failure due to 0 value not enforced

* Id: lurk-lab/lurk-rs/inference_Soundness_failure_due_to_0_value_not_enforced
* Project: https://github.com/lurk-lab/lurk-rs
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: 
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/circuits
  - Function: selector_dot_product
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Soundness failure due to 0 value not enforced
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Soundness failure due to 0 value not enforced" occurred because the variable 'zero' in the selector_dot_product() function was allocated but not enforced to be zero. This variable was used as the default in pick(), allowing the final result to be manipulated. The issue was addressed in commit 4a61333 by passing a previously allocated zero variable from the global store, ensuring it remained unaltered throughout the operation.

#### Proposed Mitigation

The bug identified as 'Soundness failure due to 0 value not enforced' was fixed by passing a previously allocated zero variable from the global store to ensure it correctly enforces the zero value. This adjustment was made as recorded in commit 4a61333.


## bellperson/lurk-lab/lurk-rs/inference_Vectors_not_constrained_to_be_of_the_same_size

### Vectors not constrained to be of the same size

* Id: lurk-lab/lurk-rs/inference_Vectors_not_constrained_to_be_of_the_same_size
* Project: https://github.com/lurk-lab/lurk-rs
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: d2c7c69efec6b36dfcb55a0586c21df88f0a00b6
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/circuits
  - Function: multi_case
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Vectors not constrained to be of the same size
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug titled "Vectors not constrained to be of the same size" involves vectors in Lurk's circuit operations not being enforced to match in size, leading to potential runtime crashes or uncaught bugs. Measures including adding assertions for size consistency have been implemented to address these issues and prevent potential soundness or runtime problems.

#### Proposed Mitigation

To fix the bug 'Vectors not constrained to be of the same size,' the recommended fix involves adding assertions in various functions to ensure vectors are the same size, preventing runtime crashes and uncaught bugs. This was implemented and validated through adjusted tests as per commit d2c7c69.


## bellperson/lurk-lab/lurk-rs/inference_Soundness_failure_due_toaccumulator_1_initial_value_not_enforced

### Soundness failure due toaccumulator 1 initial value not enforced

* Id: lurk-lab/lurk-rs/inference_Soundness_failure_due_toaccumulator_1_initial_value_not_enforced
* Project: https://github.com/lurk-lab/lurk-rs
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: 
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/circuits/multi_case_aux
  - Function: multi_case_aux
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Soundness failure due toaccumulator 1 initial value not enforced
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Soundness failure due to accumulator 1 initial value not enforced" occurs because in the function multi_case_aux, the initial accumulator variable 'acc' is set to 1 but this value is not enforced. As a result, changing this value to 0 could manipulate the variable '_selected' to always be true, affecting the soundness of the program. This issue was corrected in a code update that involved passing a global store as input and utilizing a previously allocated 'true_num' variable.

#### Proposed Mitigation

The recommended fix for the bug 'Soundness failure due to accumulator 1 initial value not enforced' is addressed by passing the global store as input and using the previously allocated true_num variable. This was implemented in commit 4a61333.


## bellperson/lurk-lab/neptune/inference_Zero_padding_not_enforced

### Zero padding not enforced

* Id: lurk-lab/neptune/inference_Zero_padding_not_enforced
* Project: https://github.com/lurk-lab/neptune
* Commit: 0x5c92c6a37856f43cb23bcfce59443da9d0ce0061
* Fix Commit: 2415d641dcbdab17b3264d2254705a382c86ce73
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: filecoin-project/neptune/src/circuit2.rs
  - Function: poseidon_hash_allocated
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/inference-lurk.pdf
  - Bug ID: Zero padding not enforced
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Zero padding not enforced" refers to an issue in the function poseidon_hash_allocated() within the neptune library, where padding with newly allocated zero variables was not enforced to be zero in scenarios where hash_type is ConstantLength and the length is smaller than the arity. This flaw potentially allowed for hash manipulation that could still pass Poseidon validation checks. It was fixed by constraining the padding values to be zero using a new function enforce_zero().

#### Proposed Mitigation

The recommended fix for the bug "Zero padding not enforced" is to ensure that zero padding values are constrained to be zero, using the function `enforce_zero()`. This fix was implemented in commit 2415d64.


# filecoin-project

## bellperson/filecoin-project/rust-fil-proofs/trapdoor_Add_missing_public_input_for_replica_id

### Add missing public input for replica-id

* Id: filecoin-project/rust-fil-proofs/trapdoor_Add_missing_public_input_for_replica-id
* Project: https://github.com/filecoin-project/rust-fil-proofs
* Commit: 8efe93
* Fix Commit: a4c25bedaaa3099e89770d704ba3bee2cbec87c3fd7e4f5fabbcb1bce7aa9fce
* DSL: Bellperson
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: storage-proofs/src/porep/stacked/vanilla/challenges.rs
  - Function: derive_internal
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trapdoor-filecoin-disclosure.pdf
  - Bug ID: Add missing public input for replica-id
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug in PoREP V25 was that the "replica_id" was not included as a public input in the proof circuit. This omission allowed for the use of a forged "replica_id" in the SDR calculation process, meaning an attacker could pre-compute the SDR values using a fake "replica_id" and bypass the intended security mechanism. Consequently, this flaw could lead to the reuse of one SDR replica calculation across multiple sectors, fundamentally undermining the integrity of the system.

#### Proposed Mitigation

The recommended fix for the vulnerability is to include the replica_id as a public input in the PoREP circuit to ensure that the SDR calculation is legitimately tied to a specified replica_id, not just any replica_id. This change would prevent the exploitation where one fixed replica_id could be used for calculations across different sectors.


# Consensys

## gnark/Consensys/gnark/Unsoundness_in_variable_comparison__non_unique_binary_decomposition

### Unsoundness in variable comparison / non-unique binary decomposition

* Id: Consensys/gnark/Unsoundness_in_variable_comparison_/_non-unique_binary_decomposition
* Project: https://github.com/Consensys/gnark
* Commit: 
* Fix Commit: 
* DSL: gnark
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/Consensys/gnark/security/advisories/GHSA-498w-5j49-vqjg
  - Bug ID: Unsoundness in variable comparison / non-unique binary decomposition
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


# scroll-tech

## halo2/scroll-tech/poseidon-circuit/zellic_mpt_only_being_true_leads_to_overconstrained_circuits

### mpt_only being true leads to overconstrained circuits

* Id: scroll-tech/poseidon-circuit/zellic_mpt_only_being_true_leads_to_overconstrained_circuits
* Project: https://github.com/scroll-tech/poseidon-circuit
* Commit: 0xf3ebc6af0e5049d2f45259ef79741f9c7d7794e1
* Fix Commit: 912f5ed2c6cacd64a0006e868e3cb4b624acc019
* DSL: Halo2
* Vulnerability: Over-Constrained
* Impact: Completeness
* Root Cause: Other Programming Errors
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/hash.rs
  - Function: 
  - Line: 11
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll.pdf
  - Bug ID: mpt_only being true leads to overconstrained circuits
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug regarding 'mpt_only' being true leads to overconstrained circuits in the Poseidon hashing implementation means that when the mpt_only flag is set to true, the circuit incorrectly constrains certain input values to zero. This results in any hashing attempts with non-zero inputs failing the ZKP verification, potentially limiting the functionality of the circuit. The issue arises from an incorrect ordering in the logic that enables the custom row within the circuit.

#### Proposed Mitigation

Change the order of the two logic statements related to mpt_only so that it correctly enables the custom gate logic. Specifically, update it as follows: if self.mpt_only { return Ok(1); } config.s_custom.enable(region, 1)?;


## halo2/scroll-tech/zkevm-circuits/trailofbits_Nondeterministic_execution_of_ReturnDataCopyGadget_and_ErrorReturnDataOutOfBoundGadget

### Nondeterministic execution of ReturnDataCopyGadget and ErrorReturnDataOutOfBoundGadget

* Id: scroll-tech/zkevm-circuits/trailofbits_Nondeterministic_execution_of_ReturnDataCopyGadget_and_ErrorReturnDataOutOfBoundGadget
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe8bcb23e1f303bd6e0dc52924b0ed85710b8a016
* Fix Commit: 48172be100d36c89256fd55337997a56ba26d711
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/evm_circuit/execution/returndatacopy.rs
  - Function: 
  - Line: 52
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll.pdf
  - Bug ID: Nondeterministic execution of ReturnDataCopyGadget and ErrorReturnDataOutOfBoundGadget
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Nondeterministic execution of ReturnDataCopyGadget and ErrorReturnDataOutOfBoundGadget" involves a failure in the constraints of the ReturnDataCopy opcode, allowing a malicious prover to execute the opcode even when in an error state with certain inputs. This can lead to a situation where the prover can arbitrarily choose to either successfully execute or halt, resulting in state divergence from the correct EVM execution. The recommendation is to implement constraints to ensure that successful execution states are disjoint from error execution states, safeguarding against exploitation.

#### Proposed Mitigation

To resolve the nondeterministic execution of the ReturnDataCopyGadget and ErrorReturnDataOutOfBoundGadget, add constraints to ensure that the successful execution state is disjoint from the error execution state, preventing a malicious prover from selecting either path during execution. Additionally, investigate other error states to guarantee their disjoint nature with associated opcode implementations.


## halo2/scroll-tech/zkevm-circuits/zellic_Highest_tx_id_must_be_equal_to_cum_num_txs_in_Tx_Circuit

### Highest tx_id must be equal to cum_num_txs in Tx Circuit

* Id: scroll-tech/zkevm-circuits/zellic_Highest_tx_id_must_be_equal_to_cum_num_txs_in_Tx_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Misimplementation of a Specification
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit/tx_circuit.rs
  - Function: 
  - Line: 66
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Highest tx_id must be equal to cum_num_txs in Tx Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Highest tx_id must be equal to cum_num_txs in Tx Circuit' indicates that in the Tx Circuit, while there is a check to ensure that tx_id is less than the cum_num_txs, there isn't a constraint enforcing that the highest tx_id must be equal to cum_num_txs. This could allow cum_num_txs to be much larger than the actual set of tx_ids, potentially leading to inconsistencies in transaction processing. It is recommended to add a constraint to verify that the last non-padding transaction's tx_id equates to cum_num_txs.

#### Proposed Mitigation

Add a constraint to ensure that the tx_id of the last non-padding transaction in the Tx Circuit is equal to cum_num_txs.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_check_in_the_initialization_on_the_state_machine_in_RLP_Circuit

### Missing check in the initialization on the state machine in RLP Circuit

* Id: scroll-tech/zkevm-circuits/zellic_Missing_check_in_the_initialization_on_the_state_machine_in_RLP_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: rlp_circuit_fsm.rs
  - Function: 
  - Line: 19
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing check in the initialization on the state machine in RLP Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug report identifies a critical issue in the RLP Circuit related to the state machine initialization, specifically a missing check that should ensure the initial state is set to "DecodeTagStart" and the initial transaction ID is set to 1. This oversight may allow the state machine to start decoding incorrectly, potentially leading to invalid RLP decodings. The issue has been acknowledged and a fix has been implemented.

#### Proposed Mitigation

Add a check to ensure that the initial state of the state machine in the RLP Circuit is set to DecodeTagStart and that the initial tx_id is 1.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_constraint_for_the_first_tx_id_in_Tx_Circuit

### Missing constraint for the first tx_id in Tx Circuit

* Id: scroll-tech/zkevm-circuits/zellic_Missing_constraint_for_the_first_tx_id_in_Tx_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit
  - Function: 
  - Line: 40
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing constraint for the first tx_id in Tx Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Missing constraint for the first tx_id in Tx Circuit" refers to the absence of a check ensuring that the initial transaction ID (tx_id) starts at 1 in the Tx Circuit. While the transitions for tx_id have been implemented correctly, there is currently no enforcement that establishes the first tx_id as equal to 1, potentially allowing it to begin at any arbitrary value. It has been recommended to add this constraint to guarantee that the first tx_id is consistently set to 1.

#### Proposed Mitigation

Add a constraint to check that the first tx_id is equal to 1 in the Tx Circuit. Remediation has already been acknowledged and implemented by Scroll in commit 2e422878.


## halo2/scroll-tech/zkevm-circuits/trailofbits_The_invalid_creation_error_handling_circuit_is_unconstrained

### The “invalid creation” error handling circuit is unconstrained

* Id: scroll-tech/zkevm-circuits/trailofbits_The_“invalid_creation”_error_handling_circuit_is_unconstrained
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xfc6c8a2972870e62e96cde480b3aa48c0cc1303d
* Fix Commit: 799450ce1434270c27e98916817935586369d8c8
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: evm_circuit/execution/error_invalid_creation_code.rs
  - Function: 
  - Line: 36
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll-2.pdf
  - Bug ID: The “invalid creation” error handling circuit is unconstrained
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The "invalid creation" error handling circuit is unconstrained, which means it does not enforce the expected condition that the first byte of the actual memory should be 0xef. This lack of constraint allows a malicious prover to redirect EVM execution to a halt state after the CREATE opcode is executed, enabling potential exploitation. Immediate action is needed to bind the first byte witness to the relevant memory value to prevent this issue.

#### Proposed Mitigation

Short-term, bind the first_byte witness value to the memory value to ensure it equals 0xef after the CREATE opcode is called. Long-term, generate malicious traces to add to the test suite for soundness verification whenever an issue is found.


## halo2/scroll-tech/zkevm-circuits/zellic_ChainId_is_not_mapped_to_its_corresponding_RLP_Tag_in_Tx_Circuit

### ChainId is not mapped to it’s corresponding RLP Tag in Tx Circuit

* Id: scroll-tech/zkevm-circuits/zellic_ChainId_is_not_mapped_to_it’s_corresponding_RLP_Tag_in_Tx_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit/tx_circuit.rs
  - Function: 
  - Line: 64
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: ChainId is not mapped to it’s corresponding RLP Tag in Tx Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'ChainId is not mapped to its corresponding RLP Tag in Tx Circuit' indicates that within the Tx Circuit, the ChainId field is incorrectly set to Null in the mapping of TxFieldTag values. This oversight means that the ChainId is omitted during lookups needed for verifying transaction signatures, potentially allowing a scenario where the ChainId value could be neglected for transaction signatures. It is recommended to add the appropriate mapping and ensure ChainId is included in RLP lookups.

#### Proposed Mitigation

Recommend adding the mapping from TxFieldTag: ChainID to the RLPTag: ChainId and ensure the ChainID value in the TxTable is looked up in the RLPTable using this mapping.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_do_not_emit!_constraints

### Missing do_not_emit! constraints

* Id: scroll-tech/zkevm-circuits/zellic_Missing_do_not_emit!_constraints
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: rlp_circuit_fsm.rs
  - Function: 
  - Line: 25
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing do_not_emit! constraints
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Missing do_not_emit! constraints' refers to the absence of necessary constraints in the RLP circuit's state transition from DecodeTagStart to LongList. Specifically, the do_not_emit! macro, which ensures that the output is marked as false for rows not representing a complete tag value, is not applied in this transition. This oversight can lead to the RlpFsmRlpTable having invalid rows with output incorrectly set to true, posing a critical security risk.

#### Proposed Mitigation

Add the missing `do_not_emit!` constraints in the `DecodeTagStart => LongList` transition to ensure that `is_output` is set to false for rows that do not represent a full tag value.


## halo2/scroll-tech/zkevm-circuits/trailofbits_Underconstrained_warm_status_on_CALL_opcodes_allows_gas_cost_forgery

### Underconstrained warm status on CALL opcodes allows gas cost forgery

* Id: scroll-tech/zkevm-circuits/trailofbits_Underconstrained_warm_status_on_CALL_opcodes_allows_gas_cost_forgery
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe8bcb23e1f303bd6e0dc52924b0ed85710b8a016
* Fix Commit: e72a6a818cbda6c14cb551573432e59fe61ce109345dd4c088508a60c27979af
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/evm_circuit/execution/callop.rs
  - Function: 
  - Line: 129-138
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll.pdf
  - Bug ID: Underconstrained warm status on CALL opcodes allows gas cost forgery
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Underconstrained warm status on CALL opcodes allows gas cost forgery' highlights a vulnerability in the zkevm-circuits where a malicious prover can manipulate the status of an address (cold or warm) during the execution of CALL-like opcodes. This allows the prover to set an address as cold erroneously, which leads to incorrect gas cost calculations for subsequent calls, potentially resulting in state divergence and financial losses. The recommendation is to add constraints to ensure that the address becomes warm as required by the EVM specification.

#### Proposed Mitigation

Add constraints to ensure that the callee address becomes warm on the CALL opcodes by constraining the variable controlling the warm status to true. Additionally, ensure initial values for access list reads reflect correct warm status as specified in the EVM documentation.


## halo2/scroll-tech/zkevm-circuits/trailofbits_ModGadget_is_underconstrained_and_allows_incorrect_MULMOD_operations_to_be_proven

### ModGadget is underconstrained and allows incorrect MULMOD operations to be proven

* Id: scroll-tech/zkevm-circuits/trailofbits_ModGadget_is_underconstrained_and_allows_incorrect_MULMOD_operations_to_be_proven
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe8bcb23e1f303bd6e0dc52924b0ed85710b8a016
* Fix Commit: 069477d3efd1b4fb19640ff1d9dcd4fb3e3c9e5f3adc646e1bfc7ad0f07a0162
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/evm_circuit/util/math_gadget/modulo.rs
  - Function: construct
  - Line: 10-44
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll.pdf
  - Bug ID: ModGadget is underconstrained and allows incorrect MULMOD operations to be proven
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug report indicates that the ModGadget circuit is underconstrained, allowing incorrect MULMOD operations to be proven. Specifically, when dividing by zero, it incorrectly permits a proof that a * b mod 0 equals a * b, contrary to the EVM specifications which dictate that the result should be zero. This vulnerability could be exploited to achieve state divergence and potentially result in financial loss.

#### Proposed Mitigation

To fix the issue with 'ModGadget being underconstrained and allowing incorrect MULMOD operations,' update the constraint for the variable `a_or_zero` to be correctly conditioned on the value of `n`. The revised constraint should ensure that `a_or_zero` is only set to `a` when `n` is not zero, and must equal zero when `n` is zero.


## halo2/scroll-tech/zkevm-circuits/zellic_The_CallDataRLC_value_in_the_fixed_assignments_is_not_validated_against_the_actual_calldata_in_Tx_Circuit

### The CallDataRLC value in the fixed assignments is not validated against the actual calldata in Tx Circuit

* Id: scroll-tech/zkevm-circuits/zellic_The_CallDataRLC_value_in_the_fixed_assignments_is_not_validated_against_the_actual_calldata_in_Tx_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit
  - Function: 
  - Line: 42
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: The CallDataRLC value in the fixed assignments is not validated against the actual calldata in Tx Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug refers to the lack of validation for the CallDataRLC value against the actual calldata in the Tx Circuit. This issue could lead to discrepancies where the calldata used may differ from what is expected, potentially undermining contract integrity. It has been identified as critical due to its high likelihood of occurrence.

#### Proposed Mitigation

The recommended fix for the bug regarding the CallDataRLC value is to add a check to ensure the consistency between the CallDataRLC and the calldata part of the Tx Circuit layout via a lookup argument.


## halo2/scroll-tech/zkevm-circuits/zellic_The_first_row_of_each_Tx_in_the_calldata_section_is_undercon__strained_in_Tx_Circuit

### The first row of each Tx in the calldata section is undercon- strained in Tx Circuit

* Id: scroll-tech/zkevm-circuits/zellic_The_first_row_of_each_Tx_in_the_calldata_section_is_undercon-_strained_in_Tx_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit
  - Function: 
  - Line: 30
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: The first row of each Tx in the calldata section is undercon- strained in Tx Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug described is that the first row of each transaction in the calldata section of the Tx Circuit is underconstrained, meaning there are no checks ensuring the starting index is 0 and appropriating the accurate initial calldata gas cost. This could allow the index and gas cost values to be manipulated, leading to incorrect data processing for transactions. Appropriate constraints should be added to rectify this issue.

#### Proposed Mitigation

The recommended fix for the bug "The first row of each Tx in the calldata section is underconstrained in Tx Circuit" is to add the necessary constraints for the first row to ensure that index = 0 and calldata_gas_cost_acc is set correctly based on the value of the first calldata byte. This would prevent malicious changes to the index and calldata_gas_cost for the first row of the transaction.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_in_MulAdd_chip

### Missing range checks in MulAdd chip

* Id: scroll-tech/zkevm-circuits/zellic_Missing_range_checks_in_MulAdd_chip
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xf3ebc6af0e5049d2f45259ef79741f9c7d7794e1
* Fix Commit: b20bed27e0a1b1345c125a2975875be555d2dff9
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: gadgets/src/mul_add.rs
  - Function: 
  - Line: 16
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll.pdf
  - Bug ID: Missing range checks in MulAdd chip
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug in the MulAdd chip relates to the absence of range checks for the individual elements used in calculations. Each element, such as 'a', 'b', 'c', and their associated limbs, must fall within specific ranges to ensure correct functionality; without these checks, the chip may accept incorrect values, potentially compromising the integrity of calculations. This issue has been classified as critical due to its potential impact on the overall functionality.

#### Proposed Mitigation

The recommended fix for the 'Missing range checks in MulAdd chip' bug is to use the RangeCheckGadget to constrain the elements used within the chip to their expected values, specifically ensuring that the limbs and carry elements are within specified ranges.


## halo2/scroll-tech/zkevm-circuits/trailofbits_Incorrect_state_transitions_can_be_proven_for_any_chunk_by_manipulating_padding_flags

### Incorrect state transitions can be proven for any chunk by manipulating padding flags

* Id: scroll-tech/zkevm-circuits/trailofbits_Incorrect_state_transitions_can_be_proven_for_any_chunk_by_manipulating_padding_flags
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe40ab9e8e78fd362c50fcd0277db79a1c9a98e60
* Fix Commit: 138b7a3d7381932d02caef4462e47f7990c72b82
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: aggregator/src/core.rs
  - Function: 
  - Line: 39
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll-3.pdf
  - Bug ID: Incorrect state transitions can be proven for any chunk by manipulating padding flags
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug regarding incorrect state transitions occurs because insufficient constraints in the aggregation circuit's padding logic allow malicious provers to create invalid proofs. Specifically, a malicious actor can manipulate padding flags to prove arbitrary state transitions or produce a proof for incorrect data transitions between chunks. This vulnerability poses a high severity risk as it could facilitate exploits that affect the integrity of state transitions within the zkEVM system.

#### Proposed Mitigation

Short-term, add constraints so that `num_valid_snarks` must be non-zero and `chunk_is_valid_cells` must not have any valid cells after padding chunks. Long-term, specify, review, and test all security-critical logic such as the aggregation padding validation thoroughly to ensure robustness against manipulation.


## halo2/scroll-tech/zkevm-circuits/zellic_padding_shift_is_underconstrained_in_the_bytecode_circuit

### padding_shift is underconstrained in the bytecode circuit

* Id: scroll-tech/zkevm-circuits/zellic_padding_shift_is_underconstrained_in_the_bytecode_circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xf3ebc6af0e5049d2f45259ef79741f9c7d7794e1
* Fix Commit: e8aecb68ccd87759dc4ea46e2cec9649a0803f5b
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/bytecode_circuit/to_poseidon_hash.rs
  - Function: 
  - Line: 13
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll.pdf
  - Bug ID: padding_shift is underconstrained in the bytecode circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "padding_shift is underconstrained in the bytecode circuit" indicates that the constraints related to the padding_shift variable are insufficient for the last byte of the bytecode. This can lead to incorrect field element generation in the Poseidon hash computation, allowing two different bytecodes to hash to the same field element. It is critical due to the potential for this under-constrained state to be exploited, and a recommendation was made to enhance the constraints for the last chunk of bytecode.

#### Proposed Mitigation

Add a constraint to the padding_shift for the last chunk of the bytecode to ensure it is set correctly, especially for cases where the bytecode length is not a multiple of 31. This will prevent different bytecodes from hashing to the same field element.


## halo2/scroll-tech/zkevm-circuits/zellic_Equality_between_tag_value_and_the_final_tag_value_acc_not_checked

### Equality between tag_value and the final tag_value_acc not checked

* Id: scroll-tech/zkevm-circuits/zellic_Equality_between_tag_value_and_the_final_tag_value_acc_not_checked
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: RLPCircuit/rlp_circuit_fsm.rs
  - Function: 
  - Line: 23
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Equality between tag_value and the final tag_value_acc not checked
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Equality between tag_value and the final tag_value_acc not checked" refers to a missing validation in the RLP circuit's state machine during the transition from the Bytes state to the DecodeTagStart state. There is no condition to ensure that the accumulated tag value (tag_value_acc) equals the final tag value (tag_value) when the tag index equals the tag length, which could result in incorrect values being stored in the RLP table. The recommendation is to implement a check to validate that tag_value and tag_value_acc are equal.

#### Proposed Mitigation

Add a check to ensure that `tag_value` is equal to `tag_value_acc` before transitioning from the Bytes state to the DecodeTagStart state. This will verify that the accumulated tag value matches the expected value.


## halo2/scroll-tech/zkevm-circuits/zellic_Block_number_constraints_are_incorrect_in_PI_circuit

### Block number constraints are incorrect in PI circuit

* Id: scroll-tech/zkevm-circuits/zellic_Block_number_constraints_are_incorrect_in_PI_circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: PICircuit/pi_circuit.rs
  - Function: 
  - Line: 36
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Block number constraints are incorrect in PI circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Block number constraints are incorrect in PI circuit" indicates that the index column for the block table, which is meant to correspond to block numbers, does not have properly enforced equality constraints. Specifically, the equality checks for the index values across rows are being executed incorrectly, allowing for potential discrepancies between the index and the actual block number. This flaw could lead to invalid results in the circuit that processes block numbers.

#### Proposed Mitigation

To fix the incorrect block number constraints in the PI circuit, the declarations for index_cells and block_number_cell, as well as the equality constraints, should be moved outside of the for loop that processes the table assignments. This ensures that the constraints are applied correctly to the entire block table.


## halo2/scroll-tech/zkevm-circuits/trailofbits_The_RlpU64Gadget_is_underconstrained_when_is_lt_128_is_false

### The RlpU64Gadget is underconstrained when is_lt_128 is false

* Id: scroll-tech/zkevm-circuits/trailofbits_The_RlpU64Gadget_is_underconstrained_when_is_lt_128_is_false
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe8bcb23e1f303bd6e0dc52924b0ed85710b8a016
* Fix Commit: 2a69a55562336a54ce2b1a13748db7cf807c8e2a
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/evm_circuit/util/math_gadget/rlp.rs
  - Function: 
  - Line: 67
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll.pdf
  - Bug ID: The RlpU64Gadget is underconstrained when is_lt_128 is false
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'The RlpU64Gadget is underconstrained when is_lt_128 is false' indicates that the RlpU64Gadget circuit, which validates RLP-encoded values, lacks a constraint to ensure that when the is_lt_128 flag is false, the value is above 127. This oversight could allow a malicious prover to manipulate the value encoding, resulting in incorrect deserialization and potential state divergence in the zkEVM context. Recommendations include adding a constraint to verify that the value exceeds this threshold when is_lt_128 is false.

#### Proposed Mitigation

To fix the bug 'The RlpU64Gadget is underconstrained when is_lt_128 is false', add a constraint to ensure that the value is above 127 when is_lt_128 is false. Long-term, implement negative tests to ensure that mismatched witness values and is_lt_128 do not satisfy the circuit constraints.


## halo2/scroll-tech/zkevm-circuits/zellic_Transition_to_new_RLP_instance_in_the_state_machine_is_un__derconstrained_in_RLP_Circuit

### Transition to new RLP instance in the state machine is un- derconstrained in RLP Circuit

* Id: scroll-tech/zkevm-circuits/zellic_Transition_to_new_RLP_instance_in_the_state_machine_is_un-_derconstrained_in_RLP_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: rlp_circuit_fsm.rs
  - Function: 
  - Line: 21
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Transition to new RLP instance in the state machine is un- derconstrained in RLP Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug regarding the "Transition to new RLP instance in the state machine" is that the constraints for transitioning between RLP instances are too lenient. Specifically, it allows cases like (tx_id', format') = (tx_id - 1, format + 1), which may lead to the same transaction appearing multiple times in the state machine. Proper checks need to be implemented to ensure valid transitions.

#### Proposed Mitigation

The recommended fix for the bug regarding the underconstraint of the transition to a new RLP instance in the state machine is to implement proper checks for the transition conditions, ensuring that (tx_id', format') cannot equal (tx_id - 1, format + 1) and that tag' must be either TxType or BeginList.


## halo2/scroll-tech/zkevm-circuits/zellic_Non_trivial_rotation_incorrectly_handled_in_ComparatorChip

### Non-trivial rotation incorrectly handled in ComparatorChip

* Id: scroll-tech/zkevm-circuits/zellic_Non-trivial_rotation_incorrectly_handled_in_ComparatorChip
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xf3ebc6af0e5049d2f45259ef79741f9c7d7794e1
* Fix Commit: 21f887d2ce44c4dc42c5ccae80c5ed94a6930954
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: gadgets/src/comparator.rs
  - Function: 
  - Line: 25
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll.pdf
  - Bug ID: Non-trivial rotation incorrectly handled in ComparatorChip
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Non-trivial rotation incorrectly handled in ComparatorChip' pertains to an issue in the implementation of comparison logic where the equality check does not account for rotation, leading to incorrect results during comparisons involving non-trivial rotations. This flaw can result in the generation of incorrect expressions in the circuit, potentially affecting circuit behavior. The recommendation is to either fix the comparison function or clearly document its limitations regarding rotations.

#### Proposed Mitigation

To fix the bug 'Non-trivial rotation incorrectly handled in ComparatorChip', the implementation of the `expr` function should be corrected to account for the rotation, or alternatively, it should be documented that the `eq_chip` result should not be used for a non-trivial rotation.


## halo2/scroll-tech/zkevm-circuits/zellic_Multiple_RLP_encodings_share_the_same_RLC_value

### Multiple RLP encodings share the same RLC value

* Id: scroll-tech/zkevm-circuits/zellic_Multiple_RLP_encodings_share_the_same_RLC_value
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: RLPCircuit/rlp_circuit_fsm.rs
  - Function: 
  - Line: 68
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Multiple RLP encodings share the same RLC value
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug report indicates that multiple RLP encodings can yield the same Random Linear Combination (RLC) value when using the formula for calculating RLC, as this formula does not account for the potential addition of arbitrary leading zeroes to an RLP tag. This creates a vulnerability where an attacker can prepend zero bytes to an encoded transaction without altering the calculated RLC value. The recommendation for mitigating this issue involves adding a separate column to track the length of the RLP tag, ensuring that the combination of RLC value and tag length remains unique.

#### Proposed Mitigation

The recommended fix for the bug "Multiple RLP encodings share the same RLC value" is to add an additional column, `tag_length`, which contains the number of bytes in an RLP tag, ensuring that the combination of `(bytes_rlc, tag_length)` will always correspond to unique RLP tags.


## halo2/scroll-tech/zkevm-circuits/zellic_The_sv_address_is_not_constrained_to_be_equal_throughout_a_single_transaction

### The sv_address is not constrained to be equal throughout a single transaction

* Id: scroll-tech/zkevm-circuits/zellic_The_sv_address_is_not_constrained_to_be_equal_throughout_a_single_transaction
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2565e254fc7d42184aaade3d8ee144fdc79fdd10
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: TxCircuit
  - Function: 
  - Line: 33
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: The sv_address is not constrained to be equal throughout a single transaction
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug states that the sv_address in the transaction circuit is not consistently constrained to be the same throughout a single transaction. This leads to a situation where an attacker could use different addresses for the caller and the ECDSA signature, potentially allowing unauthorized contract calls. The recommendation is to implement a constraint ensuring that sv_address remains equal across all rows for the same transaction.

#### Proposed Mitigation

The recommended fix for the bug regarding 'sv_address' is to add checks to ensure that sv_address is equal throughout the rows representing the same transaction. This will prevent attackers from using different addresses for the caller and the ECDSA signature's recovered address.


## halo2/scroll-tech/zkevm-circuits/zellic_The_state_machine_is_not_constrained_to_end_at_End

### The state machine is not constrained to end at End

* Id: scroll-tech/zkevm-circuits/zellic_The_state_machine_is_not_constrained_to_end_at_End
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: RLPCircuit/rlp_circuit_fsm.rs
  - Function: 
  - Line: 27
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: The state machine is not constrained to end at End
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "The state machine is not constrained to end at End" indicates that there are no constraints preventing the state machine from concluding without reaching the End state. This lack of constraint could allow the machine to skip important checks related to gas costs and other calculations during the transaction processing, potentially compromising its integrity. The recommendation for remediation includes implementing a fixed column to ensure that the state is set to End when a certain condition is met, which has been acknowledged and fixed in a subsequent commit.

#### Proposed Mitigation

The recommended fix for the bug "The state machine is not constrained to end at End" is to add a fixed column q_last, implement the assign logic, and add the constraint that the state is End if q_last is enabled.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_check_for_byte_values_in_RLP_Circuit

### Missing range check for byte values in RLP Circuit

* Id: scroll-tech/zkevm-circuits/zellic_Missing_range_check_for_byte_values_in_RLP_Circuit
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 2e422878e0d78f769e08f0b1ad1275ee039362d5
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: rlp_circuit_fsm.rs
  - Function: 
  - Line: 14
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing range check for byte values in RLP Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug involves a missing range check for byte values in the RLP Circuit, specifically in the RLP circuit's data table, where the byte values are currently only validated for padding rows and not for actual data rows. This oversight allows byte values to potentially exceed the expected range of [0, 256), which can lead to incorrect behavior in the circuit. The issue has been identified as critical and has already been acknowledged by the Scroll team, with a fix implemented.

#### Proposed Mitigation

The recommended fix for the bug 'Missing range check for byte values in RLP Circuit' is to change the condition to ensure that the actual data rows' byte values are properly range-checked by modifying the check to exclude padding rows.


## halo2/scroll-tech/zkevm-circuits/zellic_ExpCircuit_has_a_under_constrained_exponentiation_algorithm_

### ExpCircuit has a under-constrained exponentiation algorithm 

* Id: scroll-tech/zkevm-circuits/zellic_ExpCircuit_has_a_under-constrained_exponentiation_algorithm_
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xf3ebc6af0e5049d2f45259ef79741f9c7d7794e1
* Fix Commit: 9b46ddbf01393ad845e48dea77de55b9358074da
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/exp-circuit.rs
  - Function: 
  - Line: 19
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll.pdf
  - Bug ID: ExpCircuit has a under-constrained exponentiation algorithm 
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug in the ExpCircuit involves an under-constrained exponentiation algorithm where checks do not ensure that the appropriate conditions related to the exponent (specifically its parity) are met, potentially allowing incorrect calculations with malicious witness values. Although this issue does not compromise security or correctness directly, it affects the algorithm's efficiency and could lead to incorrect results in certain circumstances. A recommendation is made to add checks to verify that the first argument to the parity check is correct based on the exponent's value.

#### Proposed Mitigation

The recommended fix for the under-constrained exponentiation algorithm in ExpCircuit is to add a constraint to check that the first argument to the parity check MulAdd gadget is 2 when the parity is even (c=0).


## halo2/scroll-tech/zkevm-circuits/trailofbits_The_CREATE_and_CREATE2_opcodes_can_be_called_within_a_static_context

### The CREATE and CREATE2 opcodes can be called within a static context

* Id: scroll-tech/zkevm-circuits/trailofbits_The_CREATE_and_CREATE2_opcodes_can_be_called_within_a_static_context
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0xe8bcb23e1f303bd6e0dc52924b0ed85710b8a016
* Fix Commit: 66e8458ad6b55447e17de7f715e4395be943d682483be4a945b51f98a4cc50ae
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Misimplementation of a Specification
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: zkevm-circuits/src/evm_circuit/execution/create.rs
  - Function: 
  - Line: 39
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll.pdf
  - Bug ID: The CREATE and CREATE2 opcodes can be called within a static context
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug involves the CREATE and CREATE2 opcodes being callable within a static context, which is not allowed according to the EVM specification. Currently, there are no constraints in place to prevent these state-changing operations from being executed when the context is static, potentially allowing for unintended state changes. This could enable malicious proofs leading to state divergence.

#### Proposed Mitigation

Add a constraint to the CREATE and CREATE2 opcodes to validate that they are not called within a static call context, ensuring compliance with EVM specifications that prohibit state-changing operations during static calls. Additionally, implement tests for these opcodes when invoked within a STATICCALL context.


## halo2/scroll-tech/zkevm-circuits/zellic_Missing_range_checks_for_the_LtChip

### Missing range checks for the LtChip

* Id: scroll-tech/zkevm-circuits/zellic_Missing_range_checks_for_the_LtChip
* Project: https://github.com/scroll-tech/zkevm-circuits
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: d0e7a07e8af25220623564ef1c3ed101ce63220e
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: RLPCircuit
  - Function: 
  - Line: 17
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing range checks for the LtChip
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Missing range checks for the LtChip" indicates that the LtChip is not ensuring that the difference columns fall within a specified byte range, which delegates this check to other circuits utilizing this chip. This oversight compromises the proper functionality of the LtChip, leading to potential failures in comparison operations within the relevant circuits. Recommendations include adding necessary range checks to ensure safe usage of the comparison gadgets.

#### Proposed Mitigation

Add the necessary range checks for the diff columns in the LtChip to ensure they are within the byte range, and implement checks in the TxCircuit to verify that tx_id and cum_num_txs are within specified limits.


## halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_for_new_account_in_configure_balance

### Missing constraints for new account in configure_balance

* Id: scroll-tech/mpt-circuit/zellic_Missing_constraints_for_new_account_in_configure_balance
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: ef64eb52548946a0dd7f0ee83ce71ed8d460c405
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: MPTCircuit/gadgets/mpt_update.rs
  - Function: configure_balance
  - Line: 53
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing constraints for new account in configure_balance
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Missing constraints for new account in configure_balance' indicates that within the MPT circuit's configure_balance function, there is a lack of a required constraint that the sibling must equal zero when creating a new entry in the accounts trie and assigning the balance of the account. This omission may lead to soundness issues during the update of the balance for a new address. It is recommended to add a check to enforce that the sibling (nonce/codesize) is indeed equal to zero.

#### Proposed Mitigation

Add a constraint in the configure_balance function to ensure that the sibling is equal to 0 when the segment type is AccountLeaf3 and the path type is ExtensionNew. This will prevent potential soundness issues when updating the balance of a new address.


## halo2/scroll-tech/mpt-circuit/zellic_Incorrect_constraints_in_configure_nonce

### Incorrect constraints in configure_nonce

* Id: scroll-tech/mpt-circuit/zellic_Incorrect_constraints_in_configure_nonce
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 9aeff02e4d86e9bbecd0e420ebd3ed13a824e094
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: MPTCircuit/gadgets/mpt_update.rs
  - Function: 
  - Line: 56
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Incorrect constraints in configure_nonce
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Incorrect constraints in configure_nonce" involves issues in the MPT circuit's configure_nonce function, where the checks for the new nonce size are incorrectly based on the old nonce value. This misconfiguration can lead to improper validations of nonce values, potentially allowing invalid nonces to be accepted, which may make accounts susceptible to denial-of-service attacks. The issue was acknowledged, and a fix has been implemented.

#### Proposed Mitigation

Fix the typos in the range check for the nonce in `configure_nonce` to correctly check the new nonce size instead of the old nonce when the segment type is AccountLeaf3 and the path type is Common, as well as addressing range checks for the new nonce in other conditions.


## halo2/scroll-tech/mpt-circuit/zellic_The_OneHot_encoding_gadget_has_incorrect_constraints

### The OneHot encoding gadget has incorrect constraints

* Id: scroll-tech/mpt-circuit/zellic_The_OneHot_encoding_gadget_has_incorrect_constraints
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 9bd18782c19b5f5b2a2410b80f1ace6cd9637dcb
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Incorrect Custom Gates
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: MPTCircuit
  - Function: 
  - Line: 43
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: The OneHot encoding gadget has incorrect constraints
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug in the OneHot encoding gadget involves incorrect constraints due to a helper function that mistakenly queries the current row's binary columns instead of the previous row's values. This flaw can lead to the generation of invalid proofs in the MPT (Merkle Patricia Tree) Circuit. A fix has been acknowledged and implemented by Scroll to address this issue.

#### Proposed Mitigation

The OneHot encoding gadget has incorrect constraints due to querying the value of the binary columns representing the one-hot encoding at the current row instead of the previous row. It is recommended to fix this by using BinaryColumn::previous to query the previous row.


## halo2/scroll-tech/mpt-circuit/trailofbits_The_NonceChanged_configuration_circuit_does_not_constrain_the_new_value_nonce_value

### The NonceChanged configuration circuit does not constrain the new value nonce value

* Id: scroll-tech/mpt-circuit/trailofbits_The_NonceChanged_configuration_circuit_does_not_constrain_the_new_value_nonce_value
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0xfc6c8a2972870e62e96cde480b3aa48c0cc1303d
* Fix Commit: 
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: src/gadgets/mpt_update.rs
  - Function: 
  - Line: 1209
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll-2.pdf
  - Bug ID: The NonceChanged configuration circuit does not constrain the new value nonce value
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug pertains to the NonceChanged configuration circuit, which fails to impose constraints on the new nonce value, allowing for it to be of arbitrary length. This oversight could lead to a malicious prover updating the account node with a nonce value that exceeds the expected 8 bytes, compromising system integrity. The issue is classified as high severity due to the potential for exploitation.

#### Proposed Mitigation

To fix the bug where the NonceChanged configuration circuit does not constrain the new value nonce, enforce a single unconditional constraint for the config.new_value instead of the erroneous references to config.old_value. Additionally, implement negative testing to ensure that values exceeding 8 bytes cannot be set for the nonce.


## halo2/scroll-tech/mpt-circuit/zellic_Missing_constraints_in_configure_empty_storage

### Missing constraints in configure_empty_storage

* Id: scroll-tech/mpt-circuit/zellic_Missing_constraints_in_configure_empty_storage
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: 3ab166a4a62329ec42d44cd63fc9563ff29dea4e
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: MPTCircuit/gadgets/mpt_update.rs
  - Function: 
  - Line: 54
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing constraints in configure_empty_storage
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Missing constraints in configure_empty_storage" refers to the absence of a check ensuring that the old and new hashes are identical for empty storage entries in the MPT circuit. This is similar to the existing constraints in the "configure_empty_account" function, which ensures the same condition is met. Without this check, there could be soundness issues when proving the non-existence of storage.

#### Proposed Mitigation

To fix the missing constraints in `configure_empty_storage`, ensure that the old_hash and new_hash are equal for an empty storage entry, similar to the existing check in `configure_empty_account`. Adding this check will help avoid soundness issues when proving that storage does not exist.


## halo2/scroll-tech/mpt-circuit/zellic_Missing_range_check_for_address_values_in_MPT_Circuit

### Missing range check for address values in MPT Circuit

* Id: scroll-tech/mpt-circuit/zellic_Missing_range_check_for_address_values_in_MPT_Circuit
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0x25dd32aa316ec842ffe79bb8efe9f05f86edc33e
* Fix Commit: e4f5df31e9b3005bb5977c11aa0c3b262cfe3269
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: MPTCircuit/gadgets/mpt_update.rs
  - Function: 
  - Line: 47
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zellic-scroll-2.pdf
  - Bug ID: Missing range check for address values in MPT Circuit
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug "Missing range check for address values in MPT Circuit" relates to the lack of validation for account addresses used as MPT keys, which could lead to multiple keys being generated for the same address. This situation risks creating inconsistencies in the state trie, as the absence of range checks enables potential attackers to manipulate values. The recommendation is to implement appropriate checks to ensure address values fall within specific byte ranges.

#### Proposed Mitigation

Add appropriate range checks for the account address and associated values in the MPT Circuit, ensuring that the address is within 20 bytes (160 bits), the address_high within 16 bytes (128 bits), and the calculated address_low (before multiplication by 2^96) within 4 bytes (32 bits).


## halo2/scroll-tech/mpt-circuit/trailofbits_The_OneHot_primitive_allows_more_than_one_value_at_once

### The OneHot primitive allows more than one value at once

* Id: scroll-tech/mpt-circuit/trailofbits_The_OneHot_primitive_allows_more_than_one_value_at_once
* Project: https://github.com/scroll-tech/mpt-circuit
* Commit: 0xfc6c8a2972870e62e96cde480b3aa48c0cc1303d
* Fix Commit: 34af759e94f4b342507778145e7ae364a6d5566e
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: constraint_builder/binary_column.rs
  - Function: 
  - Line: 29-37
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-scroll-2.pdf
  - Bug ID: The OneHot primitive allows more than one value at once
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug regarding the "OneHot" primitive indicates that it permits multiple values to be set simultaneously, despite its intended functionality to enforce exclusivity among its options. This lack of constraint allows a malicious prover to potentially manipulate key values within the Merkle path-checking state machine, compromising its integrity. A fix has since been implemented to enforce constraints ensuring that only one value can be active at a time.

#### Proposed Mitigation

To fix the issue with the OneHot primitive allowing more than one value at once, enforce constraints that ensure each binary column value is Boolean, specifically by adding the condition 1 - v.or(!v) == 0.


# summa-dev

## halo2/summa-dev/summa-solvency/Constant_assignment_to_check_bug

### Constant assignment to check bug

* Id: summa-dev/summa-solvency/Constant_assignment_to_check_bug
* Project: https://github.com/summa-dev/summa-solvency
* Commit: 
* Fix Commit: 
* DSL: Halo2
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/summa-dev/summa-solvency/issues/32
  - Bug ID: Constant assignment to check bug
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


# risc0

## risc0/risc0/risc0/ghsa_zkvm_underconstrained_3reg_instructions

### zkVM underconstrained vulnerability in 3-register instructions

* Id: risc0/risc0/ghsa-g3qg-6746-3mg9
* Project: https://github.com/risc0/risc0
* Commit: 98387806fe8348d87e32974468c6f35853356ad5
* Fix Commit: 67f2d81c638bff5f4fcfe11a084ebb34799b7a89
* DSL: risc0
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Constraint
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: risc0/circuit/rv32im/src/execute/rv32im.rs
  - Function: step_compute, step_store
  - Line: 327, 504
* Source: GitHub Security Advisory
  - Source Link: https://github.com/risc0/risc0/security/advisories/GHSA-g3qg-6746-3mg9
  - Bug ID: GHSA-g3qg-6746-3mg9: zkVM Underconstrained Vulnerability
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in risc0-zkvm 2.0.0-2.0.2 are vulnerable to an attack by a malicious prover. When rs1 == rs2, the vulnerable code performs two register reads to the same address in a single memory cycle, but the circuit's memory subsystem lacks proper constraints to handle multiple accesses to the same address within one cycle, creating an underconstrained state. Reported by Christoph Hochrainer via Hackenproof bug bounty. Fixed in PR #3181 (squash merge).

#### Proposed Mitigation

Fix implemented in zirgen/pull/238 (circuit fix) and risc0/pull/3181 (risc0 update). Upgrade to risc0-zkvm version 2.1.0 or later, or risc0-circuit-rv32im version 2.0.4 or later. On-chain verifiers were disabled via estop mechanism.


## risc0/risc0/risc0/ghsa_insufficient_zkvm_validation_multistep_modes

### Insufficient zkVM validation of multi-step instruction modes

* Id: risc0/risc0/ghsa-5c79-r6x7-3jx9
* Project: https://github.com/risc0/risc0
* Commit: a165a6e3443fbc2e4f7093d7552399cd56337928
* Fix Commit: 1e6ca468f3fb94ef6939b4f7875848312a708528
* DSL: risc0
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Constraint
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: risc0/circuit/rv32im-sys/cxx/step_exec.cpp
  - Function: step_exec
  - Line: 6053-6063 (example of cross-cycle validation; 16+ similar blocks throughout file missing in buggy version)
* Source: GitHub Security Advisory
  - Source Link: https://github.com/risc0/risc0/security/advisories/GHSA-5c79-r6x7-3jx9
  - Bug ID: GHSA-5c79-r6x7-3jx9: Insufficient zkVM validation of multi-step instruction modes
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Certain RISC-V instructions require multiple zkVM cycles for execution. During the first cycle of a multi-cycle instruction, the zkVM sets a major_mode which tells the zkVM how to continue the instruction during the subsequent cycle. Prior to v1.1.0, the zkVM circuit lacked constraints to ensure that the major mode had definitively been set by the previous instruction, including missing nextMajor register, majorMux component, and extern functions (extern_isTrap, extern_setUserMode) for mode validation. This under-constrained circuit could potentially allow invalid proofs to verify.

#### Proposed Mitigation

Fixed in v1.1.0 (commit 1e6ca468f from Aug 2, 2024) by comprehensive circuit update adding: (1) nextMajor register to BodyStep, (2) majorMux and majorSelect components, (3) extern_isTrap and extern_setUserMode functions. Advisory published Sep 25, 2024 recommends >= v1.1.1. Official verifier contracts deprecated verification of <1.1.1 receipts as of October 31, 2024.


## risc0/risc0/risc0/ghsa_underconstrained_division

### Underconstrained vulnerability in division

* Id: risc0/risc0/ghsa-f6rc-24x4-ppxp
* Project: https://github.com/risc0/risc0
* Commit: c8fd3bd2e2e18ad7a5abce213a376432116db039
* Fix Commit: bef7bf580eb13d5467074b5f6075a986734d3fe5
* DSL: risc0
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Constraint
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: risc0/circuit/rv32im-sys/kernels/cxx/steps.cpp
  - Function: exec_DoDiv
  - Line: 1335-1355
* Source: GitHub Security Advisory
  - Source Link: https://github.com/risc0/risc0/security/advisories/GHSA-f6rc-24x4-ppxp
  - Bug ID: GHSA-f6rc-24x4-ppxp: Underconstrained Vulnerability Division
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Two issues were found in the risc0-circuit-rv32im circuit: (1) For some inputs to signed integer division, the circuit allowed two outputs, only one of which was valid. (2) The result of division by zero was underconstrained. This vulnerability was identified using the Picus tool from Veridise. Affected versions: risc0-zkvm >= 2.0, < 2.2.

#### Proposed Mitigation

Fixed in PR #3235 and zirgen issue #249. Upgrade to risc0-zkvm version 2.2.0 or later, or risc0-circuit-rv32im version 3.0.0 or later. On-chain verifiers were disabled via estop mechanism.


# starkware-libs

## cairo/starkware-libs/stark-perpetual/abdk_This_function_cannot_handle_the_case_when_n_risk_factor_segments_is_zero

### This function cannot handle the case when n_risk_factor_segments is zero.

* Id: starkware-libs/stark-perpetual/abdk_This_function_cannot_handle_the_case_when_n_risk_factor_segments_is_zero.
* Project: https://github.com/starkware-libs/stark-perpetual
* Commit: 0xe6189aa
* Fix Commit: 3eb3a26366f412cf8d0643f65e33d8b2eb5904fc
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: execute_batch_utils.cairo
  - Function: validate_risk_factor_function
  - Line: 78
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-perpetual.pdf
  - Bug ID: This function cannot handle the case when n_risk_factor_segments is zero.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug occurs when the function 'execute_batch_utils.cairo' cannot process a scenario where the variable 'n_risk_factor_segments' is set to zero. This situation leads to unclear behavior that may affect the function's robustness or cause unexpected results. The recommendation is to consider explicitly forbidding this case through an assertion in the code to ensure stability and predictability.

#### Proposed Mitigation

The recommended fix is to explicitly forbid the case where n_risk_factor_segments is zero via an assert.


# HerodotusDev

## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Function_doesnt_ensure_that_y_is_a_power_of_two

### Function doesn’t ensure that “y” is a power of two.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Function_doesn’t_ensure_that_“y”_is_a_power_of_two.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Function doesn’t ensure that “y” is a power of two.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_position_is_not_range_checked

### Behaviour is undefined if position is not range checked.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_position_is_not_range_checked.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Behaviour is undefined if position is not range checked.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Missing_range_checks_for_negative_values

### Missing range checks for negative values

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Missing_range_checks_for_negative_values
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: eb30c321f41880b35a7af069f7f52fd98d584616
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Missing range checks for negative values
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_offset_is_not_range_checked

### Behaviour is undefined if mmr_offset is not range checked.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_offset_is_not_range_checked.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Behaviour is undefined if mmr_offset is not range checked.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_len_is_not_range_checked

### Behaviour is undefined if mmr_len is not range checked.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_mmr_len_is_not_range_checked.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Behaviour is undefined if mmr_len is not range checked.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Implicitly_requires_value_to_fit_into_128_32_160_bits

### Implicitly requires “value” to fit into 128+32=160 bits.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Implicitly_requires_“value”_to_fit_into_128+32=160_bits.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Implicitly requires “value” to fit into 128+32=160 bits.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


## cairo/HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_peaks_len_is_not_range_checked

### Behaviour is undefined if peaks_len is not range checked.

* Id: HerodotusDev/offchain-evm-headers-processor/abdk_Behaviour_is_undefined_if_peaks_len_is_not_range_checked.
* Project: https://github.com/HerodotusDev/offchain-evm-headers-processor
* Commit: 0xb14e74a5a67bd4882383993036658a57f871e12b
* Fix Commit: af97dae8be5cca025f42da9334596de50762c855
* DSL: Cairo
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/abdk-herodotus.pdf
  - Bug ID: Behaviour is undefined if peaks_len is not range checked.
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


# 0xPolygonHermez

## pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_execution_flow_hijack

### Missing constraint in PIL leading to execution flow hijack

* Id: 0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_execution_flow_hijack
* Project: https://github.com/0xPolygonHermez/zkevm-proverjs
* Commit: 0x313dc
* Fix Commit: 9d6a8948636c05d508694a90d192a0713562ce29
* DSL: PIL
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: utils.zkasm
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/hexens-polygonzkevm.pdf
  - Bug ID: Missing constraint in PIL leading to execution flow hijack
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug titled "Missing constraint in PIL leading to execution flow hijack" involves a lacking constraint in the main.pil associated with the free input checking in zkEVM ROM. This absence allows the potential for execution flow hijack, enabling an attacker to specify arbitrary jump addresses in ROM, potentially increasing balance or causing other impacts. Furthermore, because of the missing constraint, the isNeg variable can improperly evaluate to values other than 0 or 1, thereby facilitating the unintended execution flow change. This bug was classified with a severity of Critical and has been fixed as per the report.

#### Proposed Mitigation

To fix the "Missing constraint in PIL leading to execution flow hijack" bug, add a constraint for the inNeg polynomial to ensure that it only evaluates to 0 or 1 using the equation: isNeg * (1-isNeg) = 0.


## pil/0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_proving_fake_inclusion_in_the_SMT

### Missing constraint in PIL leading to proving fake inclusion in the SMT

* Id: 0xPolygonHermez/zkevm-proverjs/hexens_Missing_constraint_in_PIL_leading_to_proving_fake_inclusion_in_the_SMT
* Project: https://github.com/0xPolygonHermez/zkevm-proverjs
* Commit: 0x313dc
* Fix Commit: 40d1846b50aa6b9e006a85fde99261a8c5c7b8f2
* DSL: PIL
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: storage.pil
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/hexens-polygonzkevm.pdf
  - Bug ID: Missing constraint in PIL leading to proving fake inclusion in the SMT
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug involves a missing binary constraint in the polynomial identity layer (PIL) of a storage state machine using Sparse Merkle Tree (SMT), which is crucial for proving (Key, Value) pair inclusions. Due to the absent constraint, it's theoretically possible to manipulate the key path traversal in the SMT proof process, enabling the proof of a fake key-value binding. This can lead to incorrect validations and potentially fraudulent activities. The PIL implementation overlooked enforcing that the key representation in traversing operations strictly adheres to binary values (0 or 1), inadvertently permitting other values that could jeopardize the integrity of tree traversal and proof verification operations. The remedy was to add a required binary constraint to ensure key traversal operations and their validations remain secure and accurate.

#### Proposed Mitigation

The recommended fix for the bug 'Missing constraint in PIL leading to proving fake inclusion in the SMT' is to add the missing binary constraint.


# penumbra-zone

## arkworks/penumbra-zone/penumbra/nccgroup_Invalid_Comparisons_on_Fixed_Point_Values_are_Accepted_by_the_Circuit_Verifier

### Invalid Comparisons on Fixed-Point Values are Accepted by the Circuit Verifier

* Id: penumbra-zone/penumbra/nccgroup_Invalid_Comparisons_on_Fixed-Point_Values_are_Accepted_by_the_Circuit_Verifier
* Project: https://github.com/penumbra-zone/penumbra
* Commit: 0xa43b594
* Fix Commit: 954b3b2e678075baf1e06279ea41bb2823e540c76ddb80ba44b52476dfd3f55f
* DSL: Arkworks
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: penumbra/crates/core/num/src/fixpoint.rs
  - Function: U128x128Var::enforce_cmp
  - Line: 428-459
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/nccgroup-penumbra.pdf
  - Bug ID: Invalid Comparisons on Fixed-Point Values are Accepted by the Circuit Verifier
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug causes an arithmetic circuit designed to compare fixed-point values to accept invalid input pairs, making such checks unreliable. Specifically, this flaw in the comparison logic within the circuit means that it may incorrectly validate comparisons as true even when one value is not genuinely greater than or less than the other, which de-secures any cryptographic mechanism relying on such comparisons for correctness assurance.

#### Proposed Mitigation

To fix the issue of invalid comparisons on fixed-point values which are accepted by the circuit verifier, modify the bit-wise comparison logic in the circuit to correctly stop at the first discrepancy between input values. Implement two Boolean variables (e.g., 'gt' for "greater than" and 'lt' for "lower than") to improve the ternary state handling during bit comparisons, ensuring that the comparisons detect true inequalities between bit sequences. Additionally, add unit tests that specifically check invalid inequalities to ensure the prover refuses to create a proof for them.


## arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_addition

### Unsound fixed-point addition

* Id: penumbra-zone/penumbra/zksecurity_Unsound_fixed-point_addition
* Project: https://github.com/penumbra-zone/penumbra
* Commit: 0xa43b594
* Fix Commit: ddab070acff5567f23eb36a4a877358f2c062d9b
* DSL: Arkworks
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: core/num
  - Function: checked_add
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-penumbra.pdf
  - Bug ID: Unsound fixed-point addition
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug 'Unsound fixed-point addition' involves a fault in the fixed-point arithmetic used in Penumbra's logic. The `checked_add` function in `U128x128Var`, a 256-bit type, underconstrains some operations, potentially leading to incorrect results. This function converts limbs to field values and adds them, tracking carry for each limb and ensuring no overflow. However, the carry bit, resulting from adding two 64-bit values that produce a 65-bit result, is not properly managed. This improper handling could erroneously set all carry bits (`c1`) to zero during proving, leading to unsound additions in certain scenarios.

#### Proposed Mitigation

To fix the issue of unsound fixed-point addition in Penumbra's circuits, Penumbra released a fix that correctly computes each limb in the circuit.


## arkworks/penumbra-zone/penumbra/zksecurity_Unsound_fixed_point_multiplication

### Unsound fixed-point multiplication

* Id: penumbra-zone/penumbra/zksecurity_Unsound_fixed-point_multiplication
* Project: https://github.com/penumbra-zone/penumbra
* Commit: 0xa43b594
* Fix Commit: 1fdbe1ea10a270180c035aeb8bb7f4a3ff25d99e
* DSL: Arkworks
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: core/num
  - Function: U128x128Var::checked_mul
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-penumbra.pdf
  - Bug ID: Unsound fixed-point multiplication
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The 'Unsound fixed-point multiplication' bug occurs when scaling two fixed-point values in the multiplication operation, leading to improper computation of the result due to incorrect limb handling. This error is critical as it impacts the accuracy of fixed-point arithmetic operations in the system, specifically in the context of financial calculations where precision is paramount. The issue lies in incorrectly accounting for overflow and implementing the truncation step required to maintain precision, essentially failing to scale back the multiplied result properly.

#### Proposed Mitigation

Penumbra fixed the issue of unsound fixed-point multiplication by correctly constraining the limbs in the circuit.


## arkworks/penumbra-zone/penumbra/zksecurity_Double_spending_due_to_incoming_viewing_key_ivk_derivation_not_constrained

### Double spending due to incoming viewing key (ivk) derivation not constrained

* Id: penumbra-zone/penumbra/zksecurity_Double_spending_due_to_incoming_viewing_key_(ivk)_derivation_not_constrained
* Project: https://github.com/penumbra-zone/penumbra
* Commit: 0xa43b594
* Fix Commit: e019839939968012ed2d24cf65bdd86d239b50e9
* DSL: Arkworks
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Out-of-Circuit Computation Not Being Constrained
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: core/keys
  - Function: IncomingViewingKeyVar::derive
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-penumbra.pdf
  - Bug ID: Double spending due to incoming viewing key (ivk) derivation not constrained
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug involving the derivation of the incoming viewing key (ivk) in Penumbra's protocols allows for potential double-spending issues due to insufficient constraints during the ivk derivation process. This security issue occurs because the ivk, which should be tightly linked to the nullifier key (nk) for correct operation, can be manipulated by a malicious user during the conversion process between circuit fields. This vulnerability could enable the spending of a note multiple times by varying the nullifier key, thus undermining the intended security guarantees of the system.

#### Proposed Mitigation

To resolve the issue of double spending due to unconstrained incoming viewing key (ivk) derivation, Penumbra addressed the problem by computing the reduced value `res` outside the circuit and proving that it correctly satisfies the equation `ivk_mod_q = quotient * r_modulus + res` modulo the circuit field `Fq`, with `quotient` being constrained to `<= 4`. This fix ensures that the modulus of the scalar field `Fr` is smaller than the circuit field `Fq`.


# arkworks-rs

## arkworks/arkworks-rs/r1cs-std/Enforce_mul_by_inverse

### Enforce mul_by_inverse

* Id: arkworks-rs/r1cs-std/Enforce_mul_by_inverse
* Project: https://github.com/arkworks-rs/r1cs-std
* Commit: 
* Fix Commit: 
* DSL: Arkworks
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: 
  - Function: 
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/arkworks-rs/r1cs-std/pull/70
  - Bug ID: Enforce mul_by_inverse
* Commands
  - Setup Environment: ``
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: ``

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```


# openvm-org

## plonky3/openvm-org/openvm/ghsa_plonky3_fri_verifier_vulnerabilities

### Plonky3 missing final polynomial degree check and randomness in FRI verifier

* Id: openvm-org/openvm/GHSA-4w7p-8f9q-f4g2
* Project: https://github.com/openvm-org/openvm
* Commit: 7548bdf844db53c0a6fc9ed9f153c54422c6cfa4
* Fix Commit: bdb4831fefed13b0741d3a052d434a9c995c6d5d
* DSL: Plonky3
* Vulnerability: Fiat-Shamir Issue
* Impact: Soundness
* Root Cause: Fiat-Shamir
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: extensions/native/recursion/src/fri/mod.rs, extensions/native/recursion/src/fri/two_adic_pcs.rs
  - Function: verify_query, verify_two_adic_pcs
  - Line: 63, 57
* Source: GitHub Security Advisory
  - Source Link: https://github.com/openvm-org/openvm/security/advisories/GHSA-4w7p-8f9q-f4g2
  - Bug ID: GHSA-4w7p-8f9q-f4g2: Plonky3 missing final polynomial degree check and randomness in FRI verifier
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

OpenVM is affected by vulnerabilities in the Plonky3 FRI verifier (Plonky3 CVE GHSA-f69f-5fx9-w9r9). Two issues exist: (1) When rolling in polynomials of lower degree, the FRI prover and verifier were adding low degree polynomials without any randomness (missing beta^2 term). A malicious prover could potentially abuse this to make high degree parts of polynomials cancel out. (2) The native FRI verifier was missing a final polynomial degree check, allowing the prover to pass in a higher than expected degree polynomial without detection. The OpenVM recursive verifier was not affected by the second vulnerability because it fixed final polynomial degree to 0 (constant), but did suffer from the first vulnerability in multi-FRI verification. Projects using OpenVM native verification SDK/CLI (verify_app_proof) are affected by both vulnerabilities. Projects using recursive verifier including EVM smart contract verifier are affected by the first vulnerability. Fixed in v1.2.0 via PR #1703.

#### Proposed Mitigation

Update recursive verifier to match Plonky3 fixes: (1) Introduce betas_squared array to precompute and cache beta^2 values for proper randomness when folding and rolling in reduced opening terms. (2) Enforce that proof.final_poly.len() equals config.final_poly_len(). Fixed in v1.2.0 by updating Plonky3 dependency and modifying OpenVM's recursive verifier implementation.


## plonky3/openvm-org/openvm/ghsa_auipc_pc_byte_decomposition_overflow

### AUIPC PC Byte Decomposition Overflow Due to Iterator Off-by-One Error

* Id: openvm-org/openvm/GHSA-jf2r-x3j4-23m7
* Project: https://github.com/openvm-org/openvm
* Commit: f41640c37bc5468a0775a38098053fe37ea3538a
* Fix Commit: 68da4b50c033da5603517064aa0a08e1bbf70a01
* DSL: Plonky3
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Other Programming Errors
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: extensions/rv32im/circuit/src/auipc/core.rs
  - Function: Rv32AuipcCoreAir::eval, Rv32AuipcCoreChip::execute_instruction
  - Line: 133, 245
* Source: GitHub Security Advisory
  - Source Link: https://github.com/openvm-org/openvm/security/advisories/GHSA-jf2r-x3j4-23m7
  - Bug ID: CVE-2025-46723, GHSA-jf2r-x3j4-23m7: Byte decomposition of pc in AUIPC chip can overflow
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The AUIPC (Add Upper Immediate to PC) chip in OpenVM's RISC-V circuit contains an off-by-one error in byte decomposition logic for the program counter. A typo in iterator method chaining (for (i, limb) in pc_limbs.iter().skip(1).enumerate()) causes enumeration to produce indices 0,1,2 when the code expects 1,2,3. This makes the condition 'if i == pc_limbs.len() - 1' never trigger for the highest limb pc_limbs[3], resulting in it being range-checked to 8 bits instead of the required 6 bits. The weakened constraint allows the decomposed representation of pc to overflow the BabyBear field, enabling a malicious prover to make the AUIPC instruction's destination register take an arbitrary incorrect value. This bug was ironically introduced as a typo while fixing a previous vulnerability (Cantina finding #21). Affected version: 1.0.0, patched in 1.1.0.

#### Proposed Mitigation

Fix the iterator method order from .skip(1).enumerate() to .enumerate().skip(1). This ensures enumeration happens before skipping, producing indices 1,2,3 as expected by the logic. With correct indices, the conditional 'if i == pc_limbs.len() - 1' triggers when i equals 3 (the last limb index), properly applying the 6-bit range check to pc_limbs[3] to prevent field overflow.


# succinctlabs

## plonky3/succinctlabs/sp1/ghsa_insufficient_range_checks_babybear_arithmetic

### Insufficient range checks of BabyBear arithmetic

* Id: succinctlabs/sp1/ghsa-f77q-r5qm-w4m8
* Project: https://github.com/succinctlabs/sp1
* Commit: 798b695ec682fd922698df2b83857ecfc17c3195
* Fix Commit: 95d5df798738aaa6b348a3684602737d6ff74014
* DSL: Plonky3
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/recursion/gnark-ffi/go/sp1/babybear/babybear.go
  - Function: invF, InvE
  - Line: 136, 255
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-f77q-r5qm-w4m8
  - Bug ID: GHSA-f77q-r5qm-w4m8: Insufficient range checks of BabyBear arithmetic
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The Gnark recursion circuit constrains arithmetic over BabyBear when the native field is BN254. Functions like invF and InvE used values generated by hints that were not appropriately range checked to ensure they were less than the BabyBear modulus, allowing potential soundness violations.

#### Proposed Mitigation

Add proper range checks in InvF and InvE functions to ensure all Bn254 values are constrained to be less than the BabyBear modulus.


## plonky3/succinctlabs/sp1/ghsa_missing_chip_ordering_validation

### Missing chip_ordering validation in STARK verifier

* Id: succinctlabs/sp1/ghsa-c873-wfhp-wx5m-1
* Project: https://github.com/succinctlabs/sp1
* Commit: 1fa7d2050e6c0a5f6fc154a395f3e967022f7035
* Fix Commit: 7e2023b2cbd3c2c8e96399ef52784dd2ec08f617
* DSL: Plonky3
* Vulnerability: Backend Issue
* Impact: Soundness
* Root Cause: Missing/Incorrect Verifier Check
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/stark/src/verifier.rs
  - Function: verify_shard
  - Line: 30
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-c873-wfhp-wx5m
  - Bug ID: GHSA-c873-wfhp-wx5m (Bug 1 of 3) Missing verifier checks and fiat-shamir observations
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In SP1's STARK verifier, the prover-provided chip_ordering is used to fetch the index of chips that have preprocessed columns. Prior to v4.0.0, validation that this chip_ordering correctly provides these indexes was missing.

#### Proposed Mitigation

Add a check that the indexed chip's name is equal to the name stored in the verifying key's chip information (implemented in v4.0.0). Added after line 131 (in buggy commit) in verify_shard.


## plonky3/succinctlabs/sp1/ghsa_allocator_overflow

### Embedded allocator overflow vulnerabilities

* Id: succinctlabs/sp1/ghsa-6248-228x-mmvh-2
* Project: https://github.com/succinctlabs/sp1
* Commit: ad212dd52bdf8f630ea47f2b58aa94d5b6e79904
* Fix Commit: aa9a8e40b6527a06764ef0347d43ac9307d7bf63
* DSL: Plonky3
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Other Programming Errors
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/zkvm/entrypoint/src/lib.rs
  - Function: read_vec_raw
  - Line: 91
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-6248-228x-mmvh
  - Bug ID: GHSA-6248-228x-mmvh: (Bug 2 of 2) Insufficient checks in the Rust verifier and embedded allocators
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

SP1's embedded allocator had two overflow vulnerabilities: (1) In read_vec_raw function (introduced in v4.0.1), the check 'ptr + capacity > MAX_MEMORY' did not use overflow-safe arithmetic for the addition. When capacity is large (e.g., near u32::MAX), ptr + capacity can wrap around to a small address, bypassing the check. This allows arbitrary memory writes - for example, if a program does two read_vec calls, the second could corrupt the first buffer's memory. (2) The heap size calculation (_end to EMBEDDED_RESERVED_INPUT_START) had no check ensuring _end <= EMBEDDED_RESERVED_INPUT_START, potentially causing heap size overflow and overlap with the hint area. The bump allocator (default) was not affected by either issue. Found during Zellic audit, fixed in v5.0.0.

#### Proposed Mitigation

Replace unsafe addition with overflow-safe variant: change 'if ptr + capacity > MAX_MEMORY' to 'if ptr.saturating_add(capacity) > MAX_MEMORY'. saturating_add clamps to usize::MAX on overflow instead of wrapping, ensuring the check cannot be bypassed. Implemented in v5.0.0 (commit aa9a8e40).


## plonky3/succinctlabs/sp1/ghsa_insufficient_observation_cumulative_sum

### Insufficient observation of cumulative sum

* Id: succinctlabs/sp1/ghsa-8m24-3cfx-9fjw
* Project: https://github.com/succinctlabs/sp1
* Commit: 6512b56296c2c5e53b10cce1a741173a3d2dde68
* Fix Commit: 79884ffb1a2d10bfd2c272f864033577a052468a
* DSL: Plonky3
* Vulnerability: Fiat-Shamir Issue
* Impact: Soundness
* Root Cause: Fiat-Shamir
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/recursion/circuit/src/stark.rs
  - Function: verify_shard
  - Line: 60
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-8m24-3cfx-9fjw
  - Bug ID: GHSA-8m24-3cfx-9fjw: Insufficient observation of cumulative sum
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the recursive verifier circuit's verify_shard function, the zeta challenge is sampled without first observing the cumulative sum values from the permutation argument into the Fiat-Shamir transcript. The vulnerability affects SP1 prior to v3.0.0, discovered during audit and fixed on October 15, 2024 in PR #1638.

#### Proposed Mitigation

Fixed in PR #1638 (Oct 15, 2024). The fix modifies verify_shard to observe both global_cumulative_sum and local_cumulative_sum for each chip's opened values into the challenger before sampling alpha and zeta challenges. Upgrade to SP1 v3.0.0 or later.


## plonky3/succinctlabs/sp1/ghsa_underconstrained_is_complete_flag

### Underconstrained is_complete flag in recursive verifier

* Id: succinctlabs/sp1/ghsa-c873-wfhp-wx5m-2
* Project: https://github.com/succinctlabs/sp1
* Commit: 4681d4f0298b387f074fc93f8254584db9d258de
* Fix Commit: 4fe8144f1d57b27503f23795320a4e0eedf464c5
* DSL: Plonky3
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/recursion/circuit/src/machine/core.rs
  - Function: verify
  - Line: 120
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-c873-wfhp-wx5m
  - Bug ID: GHSA-c873-wfhp-wx5m (Bug 2 of 3) Missing verifier checks and fiat-shamir observations
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In SP1's recursive verifier, the is_complete boolean flag is used to flag a proof of complete execution. Prior to v4.0.0, this flag was underconstrained in parts of the recursive verifier, such as the first layer of recursion. This allows proofs of partial execution to be verified as proofs of complete execution.

#### Proposed Mitigation

Add appropriate calls to the assert_complete function to constrain the correctness of the is_complete flag in all parts of the recursive verifier (implemented in v4.0.0).


## plonky3/succinctlabs/sp1/ghsa_verifier_vk_root_validation

### Missing vk_root validation in Rust verifier

* Id: succinctlabs/sp1/ghsa-6248-228x-mmvh-1
* Project: https://github.com/succinctlabs/sp1
* Commit: ad212dd52bdf8f630ea47f2b58aa94d5b6e79904
* Fix Commit: aa9a8e40b6527a06764ef0347d43ac9307d7bf63
* DSL: Plonky3
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: 
* Original Entrypoint: (same as direct)
* Direct Entrypoint: 
* Location
  - Path: crates/prover/src/verify.rs
  - Function: verify_compressed, verify_shrink, verify_deferred_proof
  - Line: 297, 335, 506
* Source: GitHub Security Advisory
  - Source Link: https://github.com/succinctlabs/sp1/security/advisories/GHSA-6248-228x-mmvh
  - Bug ID: GHSA-6248-228x-mmvh: (Bug 1 of 2) Insufficient checks in the Rust verifier and embedded allocators
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Reproduce: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Find Exploit: ``
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In SP1's native Rust verifier (crates/prover/src/verify.rs), the verify_compressed, verify_shrink, and verify_deferred_proof functions validated verification keys by checking if their hash was in the precomputed recursion_vk_map, but did not validate that the vk_root field (merkle root of all valid verifying key hashes) in the proof's public values matched the expected precomputed vk_root. This allowed a malicious prover to submit proofs with an arbitrary/invalid vk_root that would still pass verification. The recursive verifier circuit and on-chain verifier were not affected as they correctly checked this issue. Found during Zellic audit, fixed in v5.0.0 (commit aa9a8e40).

#### Proposed Mitigation

Add explicit vk_root validation in the Rust verifier: check if public_values.vk_root != self.recursion_vk_root in verify_compressed, verify_shrink, and verify_deferred_proof functions. Return InvalidPublicValues error if mismatch detected. Implemented in v5.0.0 (commit aa9a8e40 at lines 323, 366, 549).


## circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_including_ill-formed_bigints_in_public_key_commitment

### Prover can lock user funds by including ill-formed BigInts in public key commitment

* Id: succinctlabs/telepathy-circuits/trailofbits-succinct-1
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* Fix Commit: 1a88e657932edc59b51e35095618f1e1a46ceef6
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Completeness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/b0c839cef30c3c25ef41d1ad3000081784766934
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/pairing/bls12_381_hash_to_G2
  - Function: SubgroupCheckG1WithValidX
  - Line: 723-731
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-telepathy.pdf
  - Bug ID: 1. Prover can lock user funds by including ill-formed BigInts in public key comitment
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `Rotate()` template in rotate.circom fails to validate the format of BigInts in public keys. SubgroupCheckG1WithValidX assumes that its input is a properly formed BigInt, with all limbs less than 2**55. This property is not validated anywhere in the `Rotate()` template. It allows a malicious prover to manipulate public keys by inserting ill-formed BigInts, specifically by altering the y-coordinate of public keys. This manipulation can lock user funds by preventing future provers from generating valid proofs, as the circuit uses these malformed keys without proper validation. The exploit involves modifying the y coordinate in a public key to create an invalid commitment, which then updates the system's commitment state, potentially leading to incorrect or fraudulent operations.

#### Proposed Mitigation

Use `Num2Bits()` template to verify that each limb of the `pubkeysBigIntY`, witness value is less than 2**55.


## circom/succinctlabs/telepathy-circuits/veridise_template_CoreVerifyPubkeyG1_does_not_perform_input_validation_simplified

### Template CoreVerifyPubkeyG1 does not perform input validation (Simplified)

* Id: succinctlabs/telepathy-circuits/veridise-V-SUC-VUL-002-simplified
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: 9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Fix Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/bls_signature.circom
  - Function: CoreVerifyPubkeyG1ToyExample
  - Line: 77-95
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-telepathy.pdf
  - Bug ID: V-SUC-VUL-002: Template CoreVerifyPubkeyG1 does not perform input validation
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

This bug is in the circom-pairing BLS signature verification logic. pubkey, signature and hash are divided into 7-entry chunks of 55-bit data, and each entry is checked against according entry in `p`. When calling `BigLessThan()`, the output isn't verified therefore attacker can manipulate the input so that it overflows p.

#### Proposed Mitigation

In each iteration of the for loop, add a constraint `lt[idx].out === 1` to make sure the input is indeed bounded by `p`.


## circom/succinctlabs/telepathy-circuits/veridise_zero_padding_for_sha256_in_ExpandMessageXMD_is_vulnerable_to_an_overflow

### Zero Padding for Sha256 in ExpandMessageXMD is vulnerable to an overflow

* Id: succinctlabs/telepathy-circuits/veridise-V-SUC-VUL-003
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: 9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Fix Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/hash_to_field.circom
  - Function: I2OSP
  - Line: 3-23
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-telepathy.pdf
  - Bug ID: V-SUC-VUL-003: Zero Padding for Sha256 in ExpandMessageXMD is vulnerable to an overflow
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Template ExpandMessageXMD calls I2OSP(64) with `in` set to 0. In template I2OSP, numbers are represented in bigint format, a 64-byte chunk. This representation allows number much larger than scalar field modulus `p`, so attacker can compute `0 + k * p` and turn that into bigint representation and still pass the constraints.

#### Proposed Mitigation

Add assertion `assert(l < 31)` when using template I2OSP(l), so the largest possible number is 31 * 8 = 248 bit, which is less than scalar field modulus `p`.


## circom/succinctlabs/telepathy-circuits/trailofbits_prover_can_lock_user_funds_by_supplying_non-reduced_Y_values_to_G1BigIntToSignFlag

### Prover can lock user funds by supplying non-reduced Y values to G1BigIntToSignFlag

* Id: succinctlabs/telepathy-circuits/trailofbits-succinct-2
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* Fix Commit: 1a88e657932edc59b51e35095618f1e1a46ceef6
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Completeness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/b0c839cef30c3c25ef41d1ad3000081784766934
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/bls.circom
  - Function: G1BigIntToSignFlag
  - Line: 198-227
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-telepathy.pdf
  - Bug ID: 2. Prover can lock user funds by supplying non-reduced Y values to G1BigIntToSignFlag
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`G1BigIntToSignFlag` fails to check if the y-coordinate is properly reduced mod p. This missing of range check allows malicious prover to lock user funds by supplying a non-reduced y-coordinate, which can be manipulated to have a positive sign when it should be negative. This manipulation can prevent future provers from generating valid proofs, effectively halting the LightClient and trapping user funds in the bridge.

#### Proposed Mitigation

Constrain the `pubkeysBigIntY` values to be less than `p` using `BigLessThan` template.


## circom/succinctlabs/telepathy-circuits/trailofbits_incorrect_handling_of_point_doubling_can_allow_signature_forgery

### Incorrect handling of point doubling can allow signature forgery

* Id: succinctlabs/telepathy-contracts
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/b0c839cef30c3c25ef41d1ad3000081784766934
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/curve.circom
  - Function: EllipticCurveAddUnequal
  - Line: 155-227
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-telepathy.pdf
  - Bug ID: 3. Incorrect handling of point doubling can allow signature forgery
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`G1Add` calls `EllipticCurveAddUnequal`. The template `EllipticCurveAddUnequal` assumes input `a` and `b` are two unequal public keys but this is not checked. Attacker can use two same public keys to do sophisticated attacks. In such scenario, the constraint on output in `EllipticCurveAddUnequal` reduces to 0 = 0 so it is always true. In other words, attacker can do point doubling at a place where it is supposed to do point addition of two unequal EC points.

#### Proposed Mitigation

Change `G1Add` to use `EllipticCurveAdd`, which correctly handles equal inputs by checking and managing point doubling.


## circom/succinctlabs/telepathy-circuits/veridise_arrayxor_is_under_constrained

### ArrayXOR is under constrained

* Id: succinctlabs/telepathy-circuits/veridise-V-SUC-VUL-001
* Project: https://github.com/succinctlabs/telepathy-circuits
* Commit: 9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Fix Commit: b0c839cef30c3c25ef41d1ad3000081784766934
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/succinctlabs/telepathy-circuits/9c84fb0f38531718296d9b611f8bd6107f61a9b8
* Original Entrypoint: circuits/step.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/hash_to_field.circom
  - Function: ArrayXOR
  - Line: 231
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-telepathy.pdf
  - Bug ID: V-SUC-VUL-001: ArrayXOR is under constrained
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`out[i]` is assigned with `<--` but not constrained with `<==`, so it can be set to any value.

#### Proposed Mitigation

Change the code to `out[i] <== a[i] ^ b[i]`.


# zkopru-network

## circom/zkopru-network/zkopru/leastauthority_previously_correct_ownership_proof_disabled_via_code_changes

### Previously Correct Ownership Proof Disabled via Code Changes

* Id: zkopru-network/zkopru/leastauthority-previously-correct-ownership-proof-disabled-via-code-changes
* Project: https://github.com/zkopru-network/zkopru/releases/tag/audit-v1
* Commit: 4236fc8a5cbf73b7f3860d87a1a447eea8d7abd4
* Fix Commit: 6458fe4ef384d2f2198aae00e719a7f94c30f090
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/tag/audit-v1/4236fc8a5cbf73b7f3860d87a1a447eea8d7abd4
* Original Entrypoint: packages/circuits/tester/ownership_proof.test.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/ownership_proof.circom
  - Function: OwnershipProof
  - Line: 14
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/leastauthority-zkorpu.pdf
  - Bug ID: Issue C: Previously Correct Ownership Proof Disabled via Code Changes
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The circuit integrates with `EdDSAPoseidonVerifier` template from circomlib, but the `enabled` signal is set to 0, disabling the verification. There is no signature verification in the circuit, so attacker can craft some non-existent signature and still generate a valid proof.

#### Proposed Mitigation

Change the line of code to `eddsa.enabled <== 1`.


## circom/zkopru-network/zkopru/leastauthority_Circuit_Does_Not_Check_the_ERC_20_Sum_Correctly_

### Circuit Does Not Check the ERC-20 Sum Correctly 

* Id: zkopru-network/zkopru/leastauthority_Circuit_Does_Not_Check_the_ERC-20_Sum_Correctly_
* Project: https://github.com/zkopru-network/zkopru
* Commit: 4236fc8a5cbf73b7f3860d87a1a447eea8d7abd4
* Fix Commit: 30a19913ce1a018ce26a34d3d6621fcd38579171
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/zkopru-network/zkopru/4236fc8a5cbf73b7f3860d87a1a447eea8d7abd4
* Original Entrypoint: packages/circuits/impls/zk_transaction_1_1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circuits/lib/zk_transaction.circom
  - Function: ZkTransaction
  - Line: 257-274
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/leastauthority-zkorpu.pdf
  - Bug ID: Circuit Does Not Check the ERC-20 Sum Correctly 
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Clean: ``
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `ZkTransaction`, the ERC-20 sum check iterates over input notes and for each `spending_note_token_addr[i]`, computes inflow and outflow sums via `ERC20Sum`. The outflow component uses `outflow_erc20[i].addr <== spending_note_token_addr[i]`, meaning it only sums output notes whose token address matches an input note's address. Output notes with token addresses not present in any input note are completely ignored by the balance check. The constraint `inflow_erc20[i].out === outflow_erc20[i].out` only verifies per-address balance for addresses in the input set, allowing an attacker to create output notes with new token addresses and drain funds.

#### Proposed Mitigation

Enforce that output notes do not contain ERC-20 token addresses that are not present in any input (spend) note, or verify the sum across all token addresses appearing in both inputs and outputs.


# worm-privacy

## circom/worm-privacy/proof-of-burn/koukyosyumei_spend_missing_range_check

### Spend missing range checks on GreaterEqThan inputs

* Id: worm-privacy/proof-of-burn/koukyosyumei_spend_missing_range_check
* Project: https://github.com/worm-privacy/proof-of-burn
* Commit: 0802485d24fed18fe063e51bcbb0bc830585855f
* Fix Commit: 90772b1c9fe73d1452e047fe49ca4fdc346472a0
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/worm-privacy/proof-of-burn/0802485d24fed18fe063e51bcbb0bc830585855f
* Original Entrypoint: circuits/spend.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/spend.circom
  - Function: Spend
  - Line: 42-45
* Source: GitHub Issue
  - Source Link: https://github.com/worm-privacy/proof-of-burn/issues/1
  - Bug ID: #1: Spend missing range checks on GreaterEqThan inputs
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `Spend()`, the balance check uses `GreaterEqThan(252)` on `balance` and `withdrawnBalance` without first constraining either input to fit in 252 bits. `GreaterEqThan(N)` assumes both inputs are < 2^N and is known to return incorrect results when this assumption is violated (see circomlib's `comparator-overflow` advisory). Because `balance` and `withdrawnBalance` are arbitrary BN254 field elements, a prover can choose `withdrawnBalance` close to the field prime — e.g., `withdrawnBalance = 21888242871839275222246405745257275088548364400416034343698204186575808495579` with `balance = 0` — so that `sufficientBalanceChecker.out === 1` holds even though the intended unsigned comparison `balance >= withdrawnBalance` does not. The remaining `Hasher()` chain (`coinHasher`, `remainingCoinHasher`) still commits, letting a malicious prover create a valid `Spend` proof for an invalid withdrawal where `balance < withdrawnBalance`. The bug was surfaced by zkFuzz (https://github.com/Koukyosyumei/zkFuzz).

#### Proposed Mitigation

Range-check both inputs to `GreaterEqThan` to be less than 2^maxAmountBits before the comparison. The fix commit (90772b1c) replaces `GreaterEqThan(252)` with `AssertGreaterEqThan(maxAmountBits)` (introduced in `circuits/utils/assert.circom`) and parameterizes `Spend(maxAmountBits)`, instantiating it as `Spend(200)` so `balance` and `withdrawnBalance` are constrained to 200-bit values — far below the 252-bit overflow boundary.


# privacy-scaling-explorations

## circom/privacy-scaling-explorations/maci/hashcloak_data_are_not_fully_verified_during_state_update

### Data are not fully verified during state update

* Id: privacy-scaling-explorations/maci/hashcloak_Data_are_not_fully_verified_during_state_update
* Project: https://github.com/privacy-scaling-explorations/maci
* Commit: 2db5f625b67a6b810bd851950d7a42c26189088b
* Fix Commit: 6df6a4054da926b07f35c5befab4f1f8af33dcc6
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Misimplementation of a Specification
* Reproduced: False
* Codebase: dataset/codebases/circom/privacy-scaling-explorations/maci/2db5f625b67a6b810bd851950d7a42c26189088b
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circom/tallyVotes.circom
  - Function: ResultCommitmentVerifier
  - Line: 258-273
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/hashcloak-maci.pdf
  - Bug ID: Data are not fully verified during state update
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Clean: ``
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `ResultCommitmentVerifier` (tallyVotes.circom), the initial tally commitment is not verified for the first batch. The circuit computes `hz <== iz.out * currentTallyCommitmentHasher.hash` where `iz.out` is 0 when `isFirstBatch == 1`, making `hz = 0`. The constraint `hz === currentTallyCommitment` then only forces `currentTallyCommitment` to be zero without verifying it against the actual computed tally hash. A malicious coordinator can start with an arbitrary tally state for the first batch, compromising all subsequent tally results.

#### Proposed Mitigation

Add constraints to verify `currentTallyCommitment` against the computed `currentTallyCommitmentHasher.hash` even for the first batch, or initialize the tally commitment in Poll.sol with a valid and expected commitment value.


# tangle-network

## circom/tangle-network/protocol-solidity/veridise_incorrect_initialization_in_membership_circuits

### Incorrect Initialization in Membership Circuits

* Id: tangle-network/protocol-solidity/veridise_incorrect_initialization_in_membership_circuits
* Project: https://github.com/tangle-network/protocol-solidity
* Commit: 848d073bb17f0aaffc6d39f594cc59efedeaec89
* Fix Commit: eeb4fc7a4883d513e3fe3adbe2c447133ccd39f2
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/tangle-network/protocol-solidity/848d073bb17f0aaffc6d39f594cc59efedeaec89
* Original Entrypoint: circuits/test/poseidon_vanchor_2_2.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/set/membership.circom
  - Function: SetMembership
  - Line: 20
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-tangle-network-protocol-solidity.pdf
  - Bug ID: V-WBT-VUL-006
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The templates `SetMembership` try to check if an element e is in a set S by generating a constraint of the form: for all  s in S, product of (s - e) = 0. They do does this by iterating over elements s of the set S and building the product. The issue is that `product[0]` is initialized to `element` which makes the constarint to be trivailly satisfied when `element` is 0.

#### Proposed Mitigation

We recommend that `product[0]` is initialized to 1.


# aptos-labs

## circom/aptos-labs/keyless-zk-proofs/koukyosyumei_unconstrained_base64_decoded_len

### Base64DecodedLength output is declared but never constrained

* Id: aptos-labs/keyless-zk-proofs/koukyosyumei_unconstrained_base64_decoded_len
* Project: https://github.com/aptos-labs/keyless-zk-proofs
* Commit: fd160220a88a5becf0f91ea1a5425fdd537c7399
* Fix Commit: fa943244d45cb733626e54108a0ce7e10bcba5c3
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/aptos-labs/keyless-zk-proofs/fd160220a88a5becf0f91ea1a5425fdd537c7399
* Original Entrypoint: circuit/templates/generated/base64_decoded_length_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuit/templates/helpers/misc.circom
  - Function: Base64DecodedLength
  - Line: 237-266
* Source: GitHub Issue
  - Source Link: https://github.com/aptos-labs/keyless-zk-proofs/issues/50
  - Bug ID: #50: Base64DecodedLength output is declared but never constrained
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Base64DecodedLength(maxN)` declares `signal output decoded_len` but never assigns or constrains it — the body only constrains the quotient/remainder of `3*n` divided by `4` via `3*n - 4*q - r === 0` plus two `LessThan` bound checks on `r` and `q`, and the code that would have computed `decoded_len <== q + reducer` is commented out at the bottom of the template. Because `decoded_len` is a circuit output with no constraint, it is a free variable at R1CS level. The caller at `circuit/templates/mainTemplate.circom:102` binds `signal ascii_payload_len <== Base64DecodedLength(maxJWTPayloadLen)(b64_payload_len)` and then feeds `ascii_payload_len` into `HashBytesToFieldWithLen(max_ascii_jwt_payload_len)(ascii_jwt_payload, ascii_payload_len)` as the effective length of the hashed region. A malicious prover can pick any value for `decoded_len`, breaking the intended binding between the base64-decoded payload and the hash length and therefore the soundness of the JWT-payload commitment.

#### Proposed Mitigation

Assign the output with a proper constraint, e.g. `signal output decoded_len <== q;`, so the template returns the decoded length that matches the internally-enforced Euclidean division `3*n === 4*q + r`. The fix in PR #54 moves the template to `circuit/templates/helpers/base64url.circom`, renames it `Base64UrlDecodedLength`, replaces the `LessThan` bound checks with explicit `Num2Bits(2)(r)` / `Num2Bits(MAX_QUO_BITS)(q)` range checks, and adds `signal output decoded_len <== q;` so `decoded_len` is now fully constrained.


# semaphore-protocol

## circom/semaphore-protocol/semaphore/veridise_no_zero_value_validation

### No Zero Value Validation

* Id: semaphore-protocol/semaphore/veridise-V-SEM-VUL-001
* Project: https://github.com/semaphore-protocol/semaphore
* Commit: 27320f17233b18de477a74919084fba76513470f
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/semaphore-protocol/semaphore/27320f17233b18de477a74919084fba76513470f
* Original Entrypoint: packages/circuits/generated/semaphore_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/semaphore.circom
  - Function: Semaphore
  - Line: 47-88
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-semaphore.pdf
  - Bug ID: V-SEM-VUL-001: No Zero Value Validation
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `Semaphore` template, the `MerkleTreeInclusionProof` accepts any `leaf` value including `zeroValue` (the default empty-leaf value used to initialize the incremental Merkle tree). Since `hashes[0] <== leaf` has no constraint rejecting `zeroValue`, and the on-chain tree is initialized with `zeroValue` at every empty position, anyone who knows the `zeroValue` and the corresponding sibling path can generate a valid inclusion proof. This `zeroValue` acts as an implicit group member that cannot be removed and whose addition does not trigger a `MemberAdded` event, giving the group creator (or anyone who knows the value) guaranteed unauthorized access.

#### Proposed Mitigation

Add a constraint in the circuit to reject proofs where the identity commitment equals `zeroValue`, e.g., by adding a non-equality check on the leaf before the Merkle proof.


# siv-org

## circom/siv-org/verifiable-private-overrides/koukyosyumei_emitifinrange_lessthan_overflow

### EmitIfInRange LessThan missing range check on index

* Id: siv-org/verifiable-private-overrides/koukyosyumei_emitifinrange_lessthan_overflow
* Project: https://github.com/siv-org/verifiable-private-overrides
* Commit: 7bda2311d7a33dcab611cfea0c67707b0b65c24c
* Fix Commit: 7c3402dda19010e7ff6c3987b6fa72b076e9b159
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/siv-org/verifiable-private-overrides/7bda2311d7a33dcab611cfea0c67707b0b65c24c
* Original Entrypoint: circuits/generated/emit_if_in_range_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/ExtractStringFromPoint.circom
  - Function: EmitIfInRange
  - Line: 30-38
* Source: GitHub Issue
  - Source Link: https://github.com/siv-org/verifiable-private-overrides/pull/13
  - Bug ID: #13-2: EmitIfInRange LessThan missing range check on index
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`EmitIfInRange(n)` compares `index` and `range` via `component lt = LessThan(n)` and emits `out <== lt.out * value`. Neither `index` nor `range` is range-checked to fit in `n` bits, so the circomlib `LessThan` comparator is being applied outside its documented precondition (see the comparator-overflow advisory at https://github.com/BlakeMScurr/comparator-overflow). A malicious prover can choose `index` near the BN254 field prime so the internal `Num2Bits(n+1)` of `index + 2^n - range` still decomposes successfully but the intended unsigned `<` relation does not hold. zkFuzz found a counter-example for `EmitIfInRange(5)`: `range = 5`, `value = 3`, `index = p - 52` — yet `lt.out = 1` and the gadget happily emits `value = 3`, bypassing the bounds check. Inside `ExtractStringFromPoint()` this lets a prover force arbitrary `pointAsBytes[i + 1]` into `stringAsBytes[i]` regardless of the nominal `length`.

#### Proposed Mitigation

Range-check `index` (and, defensively, `range`) to fit in `n` bits before feeding them to `LessThan(n)`. The fix in PR #13 swaps `shiftedFirstByte`'s witness-only `<--` for a `RShift1(8)` gadget that internally `Num2Bits(8)`-checks the input, so after the fix `length` is at most 7 bits and the downstream `EmitIfInRange` inputs can no longer overflow the comparator — callers that expose `EmitIfInRange` as a standalone gadget should add an explicit `Num2Bits(n)(index)` before the comparison.


## circom/siv-org/verifiable-private-overrides/koukyosyumei_extractstringfrompoint_shiftedfirstbyte_unconstrained

### ExtractStringFromPoint shiftedFirstByte is assigned but not constrained

* Id: siv-org/verifiable-private-overrides/koukyosyumei_extractstringfrompoint_shiftedfirstbyte_unconstrained
* Project: https://github.com/siv-org/verifiable-private-overrides
* Commit: 7bda2311d7a33dcab611cfea0c67707b0b65c24c
* Fix Commit: 7c3402dda19010e7ff6c3987b6fa72b076e9b159
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/siv-org/verifiable-private-overrides/7bda2311d7a33dcab611cfea0c67707b0b65c24c
* Original Entrypoint: circuits/generated/extract_string_from_point_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/ExtractStringFromPoint.circom
  - Function: ExtractStringFromPoint
  - Line: 19
* Source: GitHub Issue
  - Source Link: https://github.com/siv-org/verifiable-private-overrides/pull/13
  - Bug ID: #13-1: ExtractStringFromPoint shiftedFirstByte is assigned but not constrained
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `ExtractStringFromPoint()`, the line `signal shiftedFirstByte <-- (pointAsBytes[0] >> 1);` computes the high 7 bits of `pointAsBytes[0]` using the witness-only operator `<--`, and the next line exposes it as an output with `signal output length <== shiftedFirstByte;`. The `>>` expression is never expressed as a constraint — there is no `<==` or `===` tying `shiftedFirstByte` to `pointAsBytes[0]`. At R1CS level `shiftedFirstByte` (and therefore `length`) is a free variable, so a malicious prover can pick any value for it. The per-index loop `stringAsBytes[i] <== EmitIfInRange(5)(i, length, pointAsBytes[i + 1]);` depends on that free `length`, so the extracted string bytes no longer faithfully reflect the point's first byte. zkFuzz found a counter-example where `pointAsBytes[0] = 1` (honest `length` = 0) yet the prover sets `shiftedFirstByte = 1` so `length = 1` and one extra `pointAsBytes[1]` byte is surfaced as ballot content.

#### Proposed Mitigation

Replace the `<--` assignment with a properly-constrained right-shift gadget. The fix (PR #13, merge commit `7c3402dd`) introduces a `RShift1(N)` template that does `Num2Bits(N)` on the input, shifts the bit array by one, and recomposes via `Bits2Num(N-1)`, then uses `signal shiftedFirstByte <== RShift1(8)(pointAsBytes[0]);` so every bit of `pointAsBytes[0]` is range-checked and the shifted value is deterministically tied to the input.


# personaelabs

## circom/personaelabs/spartan-ecdsa/yacademy_Knowledge_of_any_member_signature_allow_to_generate_proof_of_membership

### Knowledge of any member signature allow to generate proof of membership

* Id: personaelabs/spartan-ecdsa/yacademy_Knowledge_of_any_member_signature_allow_to_generate_proof_of_membership
* Project: https://github.com/personaelabs/spartan-ecdsa
* Commit: 3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/personaelabs/spartan-ecdsa/3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Original Entrypoint: packages/circuits/instances/pubkey_membership.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circuits/eff_ecdsa_membership/pubkey_membership.circom
  - Function: PubKeyMembership
  - Line: 17-46
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/yacademy-spartan.md
  - Bug ID: Knowledge of any member signature allow to generate proof of membership
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Clean: ``
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `PubKeyMembership` template derives a public key from ECDSA parameters via `EfficientECDSA()` and checks it against a Merkle tree root. However, the inputs `Tx`, `Ty`, `Ux`, `Uy` are unconstrained private inputs that can be freely chosen by the prover. Since `pubKey = s * T + U`, an attacker who knows any valid member signature `s` can pick arbitrary `T` and `U` values to derive any target public key in the Merkle tree, generating a valid membership proof without being a member.

#### Proposed Mitigation

Bind the ECDSA verification inputs to a specific message and public key. The circuit should constrain that the signature corresponds to a known message, preventing the prover from freely choosing `Tx`, `Ty`, `Ux`, `Uy` to target arbitrary public keys.


## circom/personaelabs/spartan-ecdsa/yacademy_input_signal_s_is_not_constrained_in_eff_ecdsa_circom

### Input signal s is not constrained in eff_ecdsa.circom

* Id: personaelabs/spartan-ecdsa/yacademy-high-01
* Project: https://github.com/personaelabs/spartan-ecdsa
* Commit: 3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/personaelabs/spartan-ecdsa/3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Original Entrypoint: packages/circuits/instances/pubkey_membership.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/eff_ecdsa.circom
  - Function: EfficientECDSA
  - Line: 25-28
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/yacademy-spartan.md
  - Bug ID: Input signal s is not constrained in eff_ecdsa.circom
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The circuit computes `pubKey = s * T + U` but `s` isn't constrained. If we set `s = 0` and `(Ux, Uy) = pubKey`, then `(Tx, Ty)` can be any pair of values.

#### Proposed Mitigation

Add constraint to `s` so that `s * T` can't be skipped in the computation.


## circom/personaelabs/spartan-ecdsa/yacademy_under_constrained_circuits_compromising_the_soundness_of_the_system

### Under constrained circuits compromising the soundness of the system

* Id: personaelabs/spartan-ecdsa/yacademy-high-03
* Project: https://github.com/personaelabs/spartan-ecdsa
* Commit: 3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/personaelabs/spartan-ecdsa/3386b30d9b5b62d8a60735cbeab42bfe42e80429
* Original Entrypoint: packages/circuits/instances/pubkey_membership.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/mul.circom
  - Function: K
  - Line: 123-124
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/yacademy-spartan.md
  - Bug ID: Under constrained circuits compromising the soundness of the system
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The signals `slo` and `shi` are assigned but not constrained

#### Proposed Mitigation

Use `<==` instead of `<--`.


# inference-labs-inc

## circom/inference-labs-inc/subnet-2-circom/koukyosyumei_clamp_comparator_overflow

### Clamp LessThan inputs are not range-checked

* Id: inference-labs-inc/subnet-2-circom/koukyosyumei_clamp_comparator_overflow
* Project: https://github.com/inference-labs-inc/subnet-2-circom
* Commit: d310309c141d36504b3486cebd96ed70ef3a4fdf
* Fix Commit: b8f92bdec1694138df0e069921f1aa0bdc94053e
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/inference-labs-inc/subnet-2-circom/d310309c141d36504b3486cebd96ed70ef3a4fdf
* Original Entrypoint: src/generated/clamp_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: src/clampTensor.circom
  - Function: Clamp
  - Line: 39-70
* Source: GitHub Issue
  - Source Link: https://github.com/inference-labs-inc/subnet-2-circom/pull/2
  - Bug ID: #2-1: Clamp LessThan inputs are not range-checked
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Clamp(b)` feeds its free field-element inputs `val`, `min`, `max`, and the intermediate `temp_max` into two invocations of `LessThan(b)` and relies on the result to pick between clamped values (`temp_1[0] <== val * (1 - LessThan[0].out); temp_2[0] <== min * LessThan[0].out;` and the analogous pair for the upper bound). The project-local `LessThan(b)` is the usual circomlib pattern (`Num2Bits(n+1)((1 << n) + in[0] - in[1])`, output is the inverse of the top bit), and it is only sound when both inputs are already bounded by `2^b`. Here none of `val`, `min`, `max`, `temp_max` is range-checked before the comparison, so this is the standard comparator-overflow scenario (see https://github.com/BlakeMScurr/comparator-overflow). A prover can set `val` close to the BN254 field prime so the `n+1`-bit decomposition of `(1 << b) + val - min` still succeeds but the unsigned ordering does not hold, letting `Clamp` return `val` when it should have returned `min` (or `max`). Downstream `clampTensor(n, b)` propagates this to the output vector, so the entire clamped tensor is attacker-controlled. The same comparator-overflow pattern is present in `DistanceFromScore`, `IntDiv`, `MetricNormalized`, `ScoringFunction`, and `ResponseTimeNormalized` in the same project — this bug is the representative entry and PR #2 fixes all of them together.

#### Proposed Mitigation

Range-check each input with `Num2Bits(b)` before it reaches the comparator. The fix (merge commit `b8f92bde`) adds `Num2Bits[0..3] = Num2Bits(b)` and feeds `val`, `min`, `max`, `temp_max` through them at the top of the template, so each is constrained to lie in `[0, 2^b)` before `LessThan(b)` is invoked.


## circom/inference-labs-inc/subnet-2-circom/koukyosyumei_subtract_unconstrained_multiplier

### Subtract uses an unconstrained multiplier d

* Id: inference-labs-inc/subnet-2-circom/koukyosyumei_subtract_unconstrained_multiplier
* Project: https://github.com/inference-labs-inc/subnet-2-circom
* Commit: d310309c141d36504b3486cebd96ed70ef3a4fdf
* Fix Commit: b8f92bdec1694138df0e069921f1aa0bdc94053e
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/inference-labs-inc/subnet-2-circom/d310309c141d36504b3486cebd96ed70ef3a4fdf
* Original Entrypoint: src/generated/subtract_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: src/subtractTensor.circom
  - Function: Subtract
  - Line: 3-10
* Source: GitHub Issue
  - Source Link: https://github.com/inference-labs-inc/subnet-2-circom/pull/2
  - Bug ID: #2-2: Subtract uses an unconstrained multiplier d
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Subtract()` defines an intermediate signal `d` that is assigned via the witness-only operator (`signal d; d <-- 1;`) and then uses it to scale the subtraction result (`c <== (a - b)*d;`). Because `d` is never tied to its value with a `===` or `<==`, it is a free variable at R1CS level — a malicious prover can choose any `d` at witness-generation time and the resulting `c = (a - b) * d` still satisfies every constraint in the circuit. The template therefore does not implement subtraction; callers such as `MetricNormalized` and `ResponseTimeNormalized`, which use `Subtract()` to compute `(value - min)` and `(max - min)`, inherit the freedom and can emit arbitrary normalized scores. The same assigned-but-unconstrained pattern also shows up in `IntDiv`'s `out <-- quot;` in this project (fixed to `out <== quot;` in the same PR) — this Subtract bug is the representative entry.

#### Proposed Mitigation

Remove the `d` multiplier entirely and constrain the output directly: `c <== a - b;`. The fix (merge commit `b8f92bde`) collapses the three-line body to that single line, eliminating the free variable.


# 0xbok

## circom/0xbok/circom-bigint/veridise_missing_range_checks_in_bigmod

### Missing range checks in BigMod

* Id: 0xbok/circom-bigint/veridise-V-BIGINT-COD-001
* Project: https://github.com/0xbok/circom-bigint
* Commit: 436665bf01728ae8c581fdb39e8428cb6b835c37
* Fix Commit: d3edd7503f48f98a71b6013c248ef3ad55e19703
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: dataset/codebases/circom/0xbok/circom-bigint/436665bf01728ae8c581fdb39e8428cb6b835c37
* Original Entrypoint: test/circuits/test_bigmod_22.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/bigint.circom
  - Function: BigMod
  - Line: 363-417
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-BIGINT-COD-001: Missing range checks in BigMod
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The bug in the BigMod template arises from missing range checks on the remainder `mod[i]`, allowing it to exceed the expected range of `2**n`. This underconstrained error can be exploited by providing inputs that result in a remainder larger than `2^n`, potentially compromising the integrity of the circuit. Proper range checks are applied to the quotient `div[i]`, but not to `mod[i]`, leaving the system vulnerable to malicious inputs that break the invariant of the modulus operation.

#### Proposed Mitigation

Add additional range checking constraints for `mod[i]`. This can be done using the Num2Bits template.


# pantherfoundation

## circom/pantherfoundation/panther-core/veridise_zaccount_renewal_kyc_expiry_not_validated

### zAccountRenewalV1 Circuit Does Not Validate KYC Certificates for Expiry

* Id: pantherfoundation/panther-core/veridise_zaccount_renewal_kyc_expiry_not_validated
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 3375335
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZAccountRenewalV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/zAccountRenewalV1.circom
  - Function: ZAccountRenewalV1
  - Line: 130-140
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-017: zAccountRenewalV1 circuit does not validate KYC certificates for expiry
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `ZAccountRenewalV1` template declares `signal input kycSignedMessageTimestamp;` and uses it as part of the signed KYC message hash (e.g. `kycSignedMessageHashInternal.inputs[1] <== kycSignedMessageTimestamp;`), but never compares it against the current `spendTime` or any expiry bound. Because KYC/KYT certificate tracking is not enforced at the smart-contract level either, the same certificate can be used for renewal after it has expired. This defeats the purpose of periodic KYC renewal — the circuit lets users keep renewing their zAccount indefinitely with a single once-issued certificate, even when the KYC rules change.

#### Proposed Mitigation

Add a circuit constraint that checks `kycSignedMessageTimestamp + kycExpiryPeriod >= spendTime` (or equivalent), rejecting expired certificates. Alternatively, track used KYC certificates at the smart-contract level and reject duplicates.


## circom/pantherfoundation/panther-core/veridise_zaccount_renewal_multiple_nullifiers_same_utxo

### zAccountRenewalV1 Can Validate Multiple Nullifiers for the Same UTXO Commitment

* Id: pantherfoundation/panther-core/veridise_zaccount_renewal_multiple_nullifiers_same_utxo
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 903edd3
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZAccountRenewalV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/zAccountRenewalV1.circom
  - Function: ZAccountRenewalV1
  - Line: 320-330
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-002: zAccountRenewalV1 can validate multiple nullifiers for the same UTXO commitment
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `ZAccountRenewalV1` template (zAccountRenewalV1.circom), the nullifier derivation uses `zAccountUtxoInNullifierHasher.privKey <== zAccountUtxoInNullifierPrivKey` and `zAccountUtxoInNullifierHasher.commitment <== zAccountUtxoInNoteHasher.out`, and the circuit later compares the hashed output against the public `zAccountUtxoInNullifier` input via `ForceEqualIfEnabled()`. However, there is **no constraint enforcing that `zAccountUtxoInNullifierPubKey[2]` is derived from `zAccountUtxoInNullifierPrivKey`**. Because `zAccountUtxoInNullifierPubKey[2]` is a separate input to the hash that builds the zAccount note commitment, the circuit accepts any `zAccountUtxoInNullifierPrivKey` that hashes to a valid nullifier — the key pair does not have to be consistent. An attacker can renew the same zAccount UTXO commitment multiple times using different `zAccountUtxoInNullifierPrivKey` values, each producing a distinct nullifier. Because the renewal flow also lets users deposit and withdraw ZKP, this enables draining the pool by re-spending the same UTXO.

#### Proposed Mitigation

Add constraints that enforce `zAccountUtxoInNullifierPubKey[2]` to be derived from `zAccountUtxoInNullifierPrivKey` via `BabyPbk` — e.g., instantiate a `BabyPbk` with `in <== zAccountUtxoInNullifierPrivKey` and force `Ax === zAccountUtxoInNullifierPubKey[0]` and `Ay === zAccountUtxoInNullifierPubKey[1]`.


## circom/pantherfoundation/panther-core/veridise_babyjubjub_suborder_constraints_not_applied_correctly

### Babyjubjub Suborder Constraints Not Applied Correctly

* Id: pantherfoundation/panther-core/veridise_babyjubjub_suborder_constraints_not_applied_correctly
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 8fdab18
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/utils.circom
  - Function: BabyJubJubSubOrderTag
  - Line: 964-975
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-001: Babyjubjub suborder constraints not applied correctly
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The template `BabyJubJubSubOrderTag(isActive)` in `utils.circom` is meant to tag its input as being less than the BabyJubJub suborder `2736030358979909402780800718157159386076813972158567259200215660948447373041`. Internally it instantiates `LessThan(251)` with inputs `in` and `suborder`, but **never constrains the output of `LessThan` to be `1`** (`n2b.out === 1` is missing) and never range-checks `in` to 251 bits. As a result the tag is vacuously applied: any field element — including `suborder + 1` — can be assigned to a signal tagged `sub_order_bj_sf`. Because `zAccountUtxoInNullifierPrivKey` is one of the signals this tag is applied to and it feeds `BabyPbk()` to derive `zAccountUtxoInNullifierPubKey` and the UTXO nullifier, an attacker can use both `privKey = 1` and `privKey = suborder + 1` to derive the same public key (they map to the same subgroup element) and generate two distinct nullifiers for the same UTXO commitment, double-spending the UTXO. Additionally, without a 251-bit input range-check, `LessThan(251)` can itself overflow and return non-deterministic results.

#### Proposed Mitigation

Inside `BabyJubJubSubOrderTag`, (1) add `n2b.out === 1;` to force the `LessThan(251)` comparison to hold, and (2) add a `Num2Bits(251)` range-check on the input `in` so that `LessThan(251)` cannot overflow.


## circom/pantherfoundation/panther-core/veridise_zone_limits_bypass_zswapv1

### Zone Related Limits Can Be Bypassed in ZSwapV1

* Id: pantherfoundation/panther-core/veridise_zone_limits_bypass_zswapv1
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 54d4d0a
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZSwapV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/zSwapV1.circom
  - Function: ZSwapV1
  - Line: 628-640
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-016: Zone related limits can be bypassed
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `ZSwapV1` template (zSwapV1.circom ~line 628), the per-zone transfer limit is implemented as:
```
component isDeltaTimeLessEqThen = LessEqThan(32);
isDeltaTimeLessEqThen.in[0] <== deltaTime;
isDeltaTimeLessEqThen.in[1] <== zZoneTimePeriodPerMaximumAmount;
signal zAccountUtxoOutTotalAmountPerTimePeriod <== Uint96Tag(ACTIVE)(
    isDeltaTimeLessEqThen.out * (totalBalanceChecker.totalWeighted +
        zAccountUtxoInTotalAmountPerTimePeriod));
```
When `deltaTime > zZoneTimePeriodPerMaximumAmount`, `isDeltaTimeLessEqThen.out` is 0 and `zAccountUtxoOutTotalAmountPerTimePeriod` collapses to 0, which always satisfies the subsequent `ForceLessEqThan(96)` comparison with `zZoneMaximumAmountPerTimePeriod`. As a result any `totalWeighted` amount — including one that exceeds the zone cap — is accepted, bypassing the zone transfer limit and breaking the compliance invariant.

#### Proposed Mitigation

The correct behavior when deltaTime exceeds the period is to reset `zAccountUtxoInTotalAmountPerTimePeriod` to 0 (new period) and re-check the cap against just `totalWeighted`, rather than collapsing the running total to 0. Fix the logic so the cap is enforced in every branch.


## circom/pantherfoundation/panther-core/veridise_zone_id_inclusion_prover_bypass

### ZoneIdInclusionProver Check Can Be Bypassed

* Id: pantherfoundation/panther-core/veridise_zone_id_inclusion_prover_bypass
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 0621e84
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/zoneIdInclusionProver.circom
  - Function: ZoneIdInclusionProver
  - Line: 30-45
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-015: ZoneIdInclusionProver check can be bypassed
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `ZoneIdInclusionProver` template (zoneIdInclusionProver.circom) is meant to verify that the caller's `zoneId` sits at position `offset` in a 16-slot `zoneIds` list. The main verification loop is `for(var i = 0; i < 15; i++)` and enables the per-slot `ForceEqualIfEnabled()` check only when `is_equal[i].out == 1` (i.e. `i == offset`). The template's assertion `assert(offset < 16);` is a compile-time `assert`, not a constraint — and the loop only iterates `i` from 0 to 14. Therefore setting `offset = 15` makes every `is_equal[i]` evaluate to 0, no ForceEqualIfEnabled is activated, and the whole zone-permission check is silently skipped. A malicious prover can bypass zone checks and send funds to a disallowed zone.

#### Proposed Mitigation

Constrain `offset` to be strictly less than 15 using a ForceLessThan(4) / LessThan() check so the silent skip is impossible, and/or iterate `i` from 0 to 15 inclusive to match the 4-bit domain of `offset`.


## circom/pantherfoundation/panther-core/veridise_kyt_signature_verification_fails_nonzero_hash

### KYT Signature Verification Process Fails for Any Non-Zero Signed Message Hash

* Id: pantherfoundation/panther-core/veridise_kyt_signature_verification_fails_nonzero_hash
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: ccb2a8b
* DSL: Circom
* Vulnerability: Over-Constrained
* Impact: Completeness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZSwapV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/trustProvidersKyt.circom
  - Function: TrustProvidersKyt
  - Line: 270-275
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-019: KYT signature verification process fails for any non-zero signed message hash
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `trustProvidersKyt.circom` around line 272, the KYT verification enable flag is computed as:
```
signal isKytDepositCheckEnabled <== BinaryTag(ACTIVE)(
    isSwap ? kytDepositSignedMessageHash * (1 - isZeroDeposit.out)
           : (1 - isZeroDeposit.out));
```
The ternary selects a value that multiplies by `kytDepositSignedMessageHash` in the swap case. Since `BinaryTag(ACTIVE)` constrains its argument to be 0 or 1, the signal has to be binary. It is 0 only when the smart contracts agree to a zero-hash; otherwise it equals the actual Poseidon hash value of the signed message, which is non-binary. For any non-zero signed message hash the BinaryTag constraint fails and the proof cannot be generated. The same bug repeats for `isKytWithdrawCheckEnabled` and `isKytInternalCheckEnabled`.

#### Proposed Mitigation

Replace `kytDepositSignedMessageHash` in the conditional with `IsNotZero()(kytDepositSignedMessageHash)` (a template that returns 0/1 depending on whether the input is zero). Apply the same fix to `kytWithdrawSignedMessageHash` and `kytSignedMessageHash`.


## circom/pantherfoundation/panther-core/veridise_nullifier_verification_can_be_disabled

### Nullifier Verification Can Be Disabled in ZSwapV1

* Id: pantherfoundation/panther-core/veridise_nullifier_verification_can_be_disabled
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 69db60e
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZSwapV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/zSwapV1.circom
  - Function: ZSwapV1
  - Line: 680-690
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-004: Nullifier verification can be disabled
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `ZSwapV1` template (zSwapV1.circom around line 680-690), the nullifier of the zAccount input UTXO is checked via:
```
component zAccountUtxoInNullifierHasherProver = ForceEqualIfEnabled();
zAccountUtxoInNullifierHasherProver.in[0] <== zAccountUtxoInNullifier;
zAccountUtxoInNullifierHasherProver.in[1] <== zAccountUtxoInNullifierHasher.out;
zAccountUtxoInNullifierHasherProver.enabled <== zAccountUtxoInSpendPrivKey;
```
The `enabled` signal of `ForceEqualIfEnabled()` is wired to `zAccountUtxoInSpendPrivKey`. An attacker can set `zAccountUtxoInSpendPrivKey = 0` — which is a valid private key that derives the neutral/infinity public key `(0, 1)` via `BabyPbk` — and this disables the entire nullifier check, allowing any value for `zAccountUtxoInNullifier`. Because this nullifier is what prevents a zAccount input UTXO from being spent twice, an attacker can spend the same zAccount UTXO infinitely many times by producing arbitrary fresh nullifier values.

#### Proposed Mitigation

Always enforce the nullifier verification by setting `zAccountUtxoInNullifierHasherProver.enabled <== 1;` instead of gating it on `zAccountUtxoInSpendPrivKey`.


## circom/pantherfoundation/panther-core/veridise_bypassing_internal_transfer_limits_via_swaps

### Bypassing internal transfer limits via swaps

* Id: pantherfoundation/panther-core/veridise_bypassing_internal_transfer_limits_via_swaps
* Project: https://github.com/pantherfoundation/panther-core
* Commit: 06a818632053719b56ace37ef12c9b31904af1e2
* Fix Commit: 39b770de49db47fcea361cf515b61e43dff36b65
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/06a818632053719b56ace37ef12c9b31904af1e2
* Original Entrypoint: circuits/circuits/mainZSwapV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/zSwapV1.circom
  - Function: ZSwapV1
  - Line: 620-631
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther-2.pdf
  - Bug ID: V-PAN-VUL-001: Bypassing internal transfer limits via swaps
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `ZSwapV1`, the per-zone internal transfer limit `zZoneInternalMaxAmount` is enforced against `utxoOutWeightedAmount[i] * isNotOwner[i]` via `ForceLessEqThan(96)`. For the swap-output UTXO (`isSwapUtxo == 1`), the protocol requires the signal `utxoOutAmount[i] === 0` because the real swapped amount is only known after the swap settles on the smart contract. Consequently `utxoOutWeightedAmount[i] <== utxoOutAmount[i] * zAssetWeight[swapToken]` is always `0`, and the comparator input `isLessThanEq_weightedUtxoOutAmount_zZoneInternalMaxAmount[i].in[0] <== utxoOutWeightedAmount[i] * isNotOwner[i]` is `0` regardless of ownership. The branch also permits `utxoOutRootSpendPubKey[i]` to be any public key, so `isNotOwner[i]` can be `1` (UTXO spendable by a different zAccount). This lets a user bypass `zZoneInternalMaxAmount` by routing the transfer as a swap UTXO assigned to another zAccount while the real transferred amount is computed off-circuit. Vulnerable code (`circuits/circuits/zSwapV1.circom:620-623`):

```
if ( isSwapUtxo ) {
    assert(zZoneInternalMaxAmount >= (utxoOutAmount[i] * zAssetWeight[swapToken] * isNotOwner[i]));
    utxoOutWeightedAmount[i] <== utxoOutAmount[i] * zAssetWeight[swapToken];
    isLessThanEq_weightedUtxoOutAmount_zZoneInternalMaxAmount[i].in[0] <== utxoOutWeightedAmount[i] * isNotOwner[i];
}
```

#### Proposed Mitigation

Enforce that swap out-UTXOs are always owned by the transacting zAccount so the implicit amount cannot leave the sender. The fix in commit `39b770d` replaces the amount-based comparison in the `isSwapUtxo` branch with an ownership check reusing the same `ForceLessEqThan` component: `isLessThanEq...in[0] <== isNotOwner[i]; isLessThanEq...in[1] <== 0;` (i.e. `isNotOwner[i] <= 0`, forcing the swap UTXO recipient to equal the sender's `zAccountUtxoInRootSpendPubKey`). Equivalently, enforce `utxoOutRootSpendPubKey[i] === zAccountUtxoInRootSpendPubKey` when `isSwapUtxo`.


## circom/pantherfoundation/panther-core/veridise_fortxreward_abstracted_away_in_reward_calc

### forTxReward Gets Abstracted Away in the Reward Calculation

* Id: pantherfoundation/panther-core/veridise_fortxreward_abstracted_away_in_reward_calc
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 1055906
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/rewardsExtended.circom
  - Function: RewardsExtended
  - Line: 20-85
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-020: forTxReward gets abstracted away in the reward calculation
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `RewardsExtended(nUtxoIn)` template (rewardsExtended.circom), the final reward `amountPrp` is computed via `S1 <== forTxReward;` (line ~44, where the comment claims `// 2^40`), and later `R <== S1 + S5;` (line ~70), then the result is divided by `prpScaleFactor = 60` by extracting the upper bits via `Num2Bits(253)` → `Bits2Num(253 - prpScaleFactor)`. Because `forTxReward` is at most 2^40 but is not pre-scaled by 2^60, after the `>> 60` truncation its contribution to `amountPrp` is exactly 0. The `S5` term dominates (~2^152), so any `forTxReward` value effectively vanishes from the reward accounting. Users therefore receive no reward for doing the transaction itself.

#### Proposed Mitigation

Add `forTxReward * 2**prpScaleFactor` to `S1`, or add `forTxReward` to `S5` after the division so that its contribution is preserved in PRP units rather than scaled-down units.


## circom/pantherfoundation/panther-core/veridise_data_escrow_encrypted_message_wrong_input

### Data Escrow Encrypted Message Constructed From Incorrect Input

* Id: pantherfoundation/panther-core/veridise_data_escrow_encrypted_message_wrong_input
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 7ff5ba7
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Other Programming Errors
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/dataEscrowElGamalEncryption.circom
  - Function: DataEscrowElGamalEncryption
  - Line: 148-152
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-021: Data escrow encrypted message constructed from incorrect input
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The template `DataEscrowElGamalEncryption(PaddingPointsSize, ScalarsSize, PointsSize)` constructs ElGamal-like ciphertexts as `M + ephemeralRandom * pubKey + HidingPoint`. For the padding-point segment the circuit builds two intermediaries: `drv_mGrY[j]` = `M + SharedPubKey` and `drv_mGrY_final[j]` = `drv_mGrY[j] + HidingPoint`. The ciphertext must use `drv_mGrY_final`, but the code at line ~150 writes:
```
encryptedMessage[j][0] <== drv_mGrY[j].xout;
encryptedMessage[j][1] <== drv_mGrY[j].yout;
```
for the padding segment — the hiding point is omitted. The scalar and point segments correctly use `drv_mGrY_final`. Because the hiding point is what ensures that UTXOs from the same sender but destined for different receivers cannot be correlated, omitting it on the padding segment breaks this privacy guarantee.

#### Proposed Mitigation

Replace `drv_mGrY[j].xout` / `drv_mGrY[j].yout` in the padding-segment assignment with `drv_mGrY_final[j].xout` / `drv_mGrY_final[j].yout` so that the hiding point is included in every ciphertext entry.


## circom/pantherfoundation/panther-core/veridise_blacklist_states_not_representable_in_field

### Blacklist States Cannot Be Represented Within the Circom Field

* Id: pantherfoundation/panther-core/veridise_blacklist_states_not_representable_in_field
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 1763ca4
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Completeness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/zAccountBlackListLeafInclusionProver.circom
  - Function: ZAccountBlackListLeafInclusionProver
  - Line: 18-80
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-009: Blacklist states cannot be represented within the circom field
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `ZAccountBlackListLeafInclusionProver(ZAccountBlackListMerkleTreeDepth)` template encodes blacklist status by using a 254-bit Merkle leaf where each bit marks whether a zAccountId is banned. Internally it uses `component n2b_leaf = Num2Bits(254); n2b_leaf.in <== leaf;` and a `for(var i = 0; i < 254; i++)` loop that ANDs `is_zero[i].out * n2b_leaf.out[i]`. However, the BN254 scalar field `p` is smaller than `2^254`, so valid 254-bit leaves that represent specific blacklist states — e.g. `2^253 + 2^252 + 2^251` to ban zAccountIds 251, 252 and 253 simultaneously — exceed `p` and cannot be represented as a field element. For such states there is no valid assignment of `leaf` for which the Merkle inclusion proof succeeds, so banning those zAccountIds becomes impossible. A malicious entity that controls the leaf value can keep it in a state whose next update would exceed `p`, locking their co-tenants out of the blacklist.

#### Proposed Mitigation

Increase the `ZAccountBlackListMerkleTree` depth to 17 and decrease the leaf bit space to 128 so that every blacklist state is representable. Alternatively, in `_getNextZAccountId` skip values 253–255 for the 8 LSBs so the leaf only ever needs 253 bits.


## circom/pantherfoundation/panther-core/veridise_unsafe_num2bits_254_blacklist_leaf

### Unsafe Use of Num2Bits(254) on Blacklist Leaf

* Id: pantherfoundation/panther-core/veridise_unsafe_num2bits_254_blacklist_leaf
* Project: https://github.com/pantherfoundation/panther-core
* Commit: b464348b33155a5877f67c085c7206dc29ad7cb7
* Fix Commit: 6dfcc56
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/pantherfoundation/panther-core/b464348b33155a5877f67c085c7206dc29ad7cb7
* Original Entrypoint: circuits/circuits/mainZTransactionV1.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/templates/zAccountBlackListLeafInclusionProver.circom
  - Function: ZAccountBlackListLeafInclusionProver
  - Line: 54-80
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-panther.pdf
  - Bug ID: V-PAN-VUL-010: Unsafe use of Num2Bits(254) on blacklist leaf
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The template `ZAccountBlackListLeafInclusionProver` uses `component n2b_leaf = Num2Bits(254); n2b_leaf.in <== leaf;` to expand the blacklist leaf into 254 bits. Circomlib's `Num2Bits(n)` only asserts `lc1 === in` and `out[i] * (out[i] - 1) === 0`; it does **not** check that the reconstructed value is canonical modulo the prime `p`. Because `p < 2^254`, two distinct 254-bit strings can recompute to the same field element modulo `p`, so a malicious prover can choose the bit decomposition to clear the bit corresponding to their `zAccountId` (`n2b_leaf.out[i] == 0`) while the leaf value itself still encodes a ban. The subsequent check `is_zero[i].out * n2b_leaf.out[i] === 0` then passes, letting a banned zAccountId pass inclusion.

#### Proposed Mitigation

Use circomlib's `Num2Bits_strict()` (or a range-checked equivalent) instead of `Num2Bits(254)` so the bit decomposition is unique modulo `p`.


# Unirep

## circom/Unirep/Unirep/veridise_missing_range_checks_on_comparison_circuits

### Missing Range Checks on Comparison Circuits

* Id: Unirep/Unirep/veridise-V-UNI-VUL-002
* Project: https://github.com/Unirep/Unirep
* Commit: 0985a28c38c8b2e7b7a9e80f43e63179fdd08b89
* Fix Commit: f7b0bcd39383d5ec4d17edec2ad91bc01333bf36
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/Unirep/Unirep/0985a28c38c8b2e7b7a9e80f43e63179fdd08b89
* Original Entrypoint: packages/circuits/generated/epochKeyLite.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/epochKeyLite.circom
  - Function: EpochKeyLite
  - Line: 45-48
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-unirep.pdf
  - Bug ID: V-UNI-VUL-002: Missing Range Checks on Comparison Circuits
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Input of `LessThan(8)` is assumed to have <=8 bits, but there is no constraint for it in `LessThan` template. Attacker can use large values such as `p - 1` to trigger overflow and make something like `p - 1 < EPOCH_KEY_NONCE_PER_EPOCH` return true.

#### Proposed Mitigation

Implement range check so that attacker can't exploit overflow in `LessThan`.


## circom/Unirep/Unirep/veridise_underconstrained_circuit_allows_invalid_comparison

### Underconstrained Circuit allows Invalid Comparison

* Id: Unirep/Unirep/veridise-V-UNI-VUL-001
* Project: https://github.com/Unirep/Unirep
* Commit: 0985a28c38c8b2e7b7a9e80f43e63179fdd08b89
* Fix Commit: 3348caa362d5d632d29c532ffa88023d55628eab
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Arithmetic Field Issues
* Reproduced: False
* Codebase: dataset/codebases/circom/Unirep/Unirep/0985a28c38c8b2e7b7a9e80f43e63179fdd08b89
* Original Entrypoint: packages/circuits/generated/bigComparators.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/bigComparators.circom
  - Function: BigLessThan
  - Line: 45
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-unirep.pdf
  - Bug ID: V-UNI-VUL-001: Underconstrained Circuit allows Invalid Comparison
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Num2Bits(254)` is used so malicious prover can provide input that is larger than scalar field modulus `p` but smaller than `2**254`, exploiting the overflow. That makes some comparison opertions invalid, for example, `1 < p` evaluates to true but in the circuit it is treated as `1 < 0`.

#### Proposed Mitigation

Use `Num2Bits_strict` rather than `Num2Bits(254)`.


# Rate-Limiting-Nullifier

## circom/Rate-Limiting-Nullifier/circom-rln/veridise_spammers_may_slash_themselves

### Spammers may slash themselves

* Id: Rate-Limiting-Nullifier/circom-rln/veridise_spammers_may_slash_themselves
* Project: https://github.com/Rate-Limiting-Nullifier/circom-rln
* Commit: 022b690b5615d1e26874013cf216136875d8f3ab
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/Rate-Limiting-Nullifier/circom-rln/022b690b5615d1e26874013cf216136875d8f3ab
* Original Entrypoint: circuits/withdraw.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/withdraw.circom
  - Function: Withdraw
  - Line: 5-11
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-rln.pdf
  - Bug ID: RLN-001: Spammers may slash themselves
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `Withdraw` template in `withdraw.circom` only proves knowledge of the pre-image of an `identityCommitment` via `signal output identityCommitment <== Poseidon(1)([identitySecret])`, with `addressHash` declared as `signal input addressHash;` and exposed as the sole public input through `component main { public [addressHash] } = Withdraw();`. Because `addressHash` participates in no constraint at the circuit level (it is only referenced by the surrounding smart contract as the slashing-reward beneficiary), a malicious registered user (Alice) who observes an incoming slash request targeting her own `identityCommitment` can construct a new `Withdraw` proof using her own `identitySecret` and her own `addressHash`, then front-run the original slasher's transaction. Because Alice knows her own `identitySecret`, she can also preemptively self-slash after sending pre-determined messages, recovering her staked economic collateral and defeating the spam-resistance guarantee. The circuit itself is satisfiable and correct as a proof-of-knowledge, but the protocol design lets the slashee perform the slashing.

#### Proposed Mitigation

Split the stake so the slasher only receives a portion of the economic collateral (e.g., half burned or distributed to other protocol participants), or require `Withdraw` to provide proof of knowledge of two distinct `identity_secret_hash` pre-images (one proving Merkle-tree membership as the slasher, and one being the identity to slash), doubling the stake required to self-slash. The deployed RLN contract addresses this by taking a fee on slash/withdraw and by freezing withdrawals for `n` blocks to allow other users to slash first.


# darkforest-eth

## circom/darkforest-eth/darkforest-v0.3/daira_hopwood_darkforest_v0_3_missing_bit_length_check

### Dark Forest v0.3: Missing Bit Length Check

* Id: darkforest-eth/darkforest-v0.3/Daira-Hopwood-Missing-Bit-Length-Check
* Project: https://github.com/darkforest-eth/darkforest-v0.3
* Commit: 1c83685e22e0463d5481c83e21616745b3204c9c
* Fix Commit: https://github.com/darkforest-eth/circuits/commit/1b5c8440a487614d4a3e6ed523df0aee71a05b6e#diff-440e6bdf86d42398f40d29b9df0b9e6992c6859194d2a7f3c8c68fb46d0f2040
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/darkforest-eth/darkforest-v0.3/1c83685e22e0463d5481c83e21616745b3204c9c
* Original Entrypoint: circuits/init/circuit.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/range_proof/circuit.circom
  - Function: RangeProof
  - Line: 16-22
* Source: Bug Tracker
  - Source Link: https://github.com/0xPARC/zk-bug-tracker
  - Bug ID: Dark Forest v0.3: Missing Bit Length Check
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Input of `LessThan(bits)` is assumed to take inputs bounded by `2**(bits-1)`, but there is no constraint for it in `LessThan` template. Attacker can use unexpected values outside the range and pass all the constraints, rendering this RangeProof useless. Note: The original circuit does not contain the output `out`, it was added to prevent snarkJS 'Scalar size does not match' error.

#### Proposed Mitigation

Add constraints to check the range of `in` and `max_abs_value`. This can be done using the `Num2Bits` template.


# sismo-core

## circom/sismo-core/hydra-s2-zkps/veridise_private_information_leakage

### Private Information Leakage

* Id: sismo-core/hydra-s2-zkps/veridise_private_information_leakage
* Project: https://github.com/sismo-core/hydra-s2-zkps
* Commit: 2b79ab31ebf5547cf73d0441a236446e8ddf501c
* Fix Commit: 
* DSL: Circom
* Vulnerability: Private Information Leakage
* Impact: ZK/Privacy
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/sismo-core/hydra-s2-zkps/2b79ab31ebf5547cf73d0441a236446e8ddf501c
* Original Entrypoint: circuits/generated/hydra-s2_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/hydra-s2.circom
  - Function: hydraS2
  - Line: 116-131
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-sismo.pdf
  - Bug ID: V-SH2-VUL-001: Private Information Leakage
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In the `hydraS2(registryTreeHeight, accountsTreeHeight)` template, the private `sourceValue` is compared against the public `statementValue` unconditionally. The circuit runs `component leq = LessEqThan(252); leq.in[0] <== statementValue; leq.in[1] <== sourceValue; leq.out === 1;` and then `sourceValue === sourceValue + ((statementValue - sourceValue) * statementComparator);`. The first block enforces `statementValue <= sourceValue` regardless of the value of `statementComparator`, so whenever a valid proof is produced the verifier learns a public lower bound on the private `sourceValue`. The `statementComparator` flag only controls whether equality is also enforced (when `statementComparator == 1`, `sourceValue === statementValue`), but it does not disable the lower-bound comparison. A user who sets `statementComparator = 0` expecting to hide their `sourceValue` still leaks the inequality `statementValue <= sourceValue` to the verifier.

#### Proposed Mitigation

Make the decision to enable the lower-bound comparison between `sourceValue` and `statementValue` explicit, analogously to how the equality check is gated by `statementComparator`. For example, introduce a separate `statementComparisonEnabled` public input (or reuse an existing flag) and replace `leq.out === 1;` with `(leq.out - 1) * statementComparisonEnabled === 0;` so that the comparison can be fully turned off when the user does not want to leak a lower bound on `sourceValue`.


# banyancomputer

## circom/banyancomputer/hot-proofs-blake3-circom/koukyosyumei_checkdepth_comparator_overflow

### Blake3NovaTreePath_CheckDepth LessThan/GreaterEqThan missing range checks

* Id: banyancomputer/hot-proofs-blake3-circom/koukyosyumei_checkdepth_comparator_overflow
* Project: https://github.com/banyancomputer/hot-proofs-blake3-circom
* Commit: 76b83107eb00c8f886bde82172eaa3cdd5d57f25
* Fix Commit: e37eb56e29b304024055f3d0a1681e6f22132ecc
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/banyancomputer/hot-proofs-blake3-circom/76b83107eb00c8f886bde82172eaa3cdd5d57f25
* Original Entrypoint: circuits/main/check_depth_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/blake3_nova.circom
  - Function: Blake3NovaTreePath_CheckDepth
  - Line: 13-39
* Source: GitHub Issue
  - Source Link: https://github.com/banyancomputer/hot-proofs-blake3-circom/issues/10
  - Bug ID: #10: Blake3NovaTreePath_CheckDepth LessThan/GreaterEqThan missing range checks
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Blake3NovaTreePath_CheckDepth()` feeds `depth` and `leaf_depth` — both free field-element inputs — directly into `component check_parent = LessThan(8)` and `component exceed_depth = GreaterEqThan(8)`, relying on the outputs to enforce that the current node lies strictly below the leaf layer (`exceed_depth.out === 0`, `check_parent.out ==> is_parent`). Neither input is first range-checked via `Num2Bits(8)` or equivalent, so both comparators are applied outside their documented precondition. This is the standard circomlib comparator-overflow (see https://github.com/BlakeMScurr/comparator-overflow): a prover can choose `depth` near the BN254 field prime so the internal `Num2Bits(9)` of `depth + 2^8 - leaf_depth` still decomposes successfully and the high bit flips the way the prover wants. zkFuzz found a counter-example with `depth = 21888242871839275222246405745257275088548364400416034343698204186575808495544` (i.e. `p - 73`) and `leaf_depth = 10` — `exceed_depth.out` evaluates to `0`, so the depth-bound check passes even though `depth` is nowhere near `< leaf_depth` in the intended unsigned sense. This lets a malicious prover forge a Merkle path that claims to terminate at an arbitrary layer of the Blake3 tree.

#### Proposed Mitigation

Range-check both inputs with `Num2Bits(8)` before feeding them to the comparators. The fix (merge commit `e37eb56e`) adds `component n2b_depth = Num2Bits(8); n2b_depth.in <== depth;` and the analogous gadget for `leaf_depth` at the top of the template so the `LessThan(8)` / `GreaterEqThan(8)` precondition is now enforced. Other templates in the project that use `LessThan`, `LessEqThan`, `GreaterThan`, or `GreaterEqThan` should get the same treatment, as called out in the issue.


# selfxyz

## circom/selfxyz/self/zksecurity_missing_byte_range_checks_allows_packed_data_pollution

### Missing Byte Range Checks Allows Packed Data Pollution

* Id: selfxyz/self/zksecurity_missing_byte_range_checks_allows_packed_data_pollution
* Project: https://github.com/selfxyz/self
* Commit: 3905a30aeb19016d22c5493b8b34ade2d118da4e
* Fix Commit: 285f0a9776514c1f03f546d1a03a4da588ba098d
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/3905a30aeb19016d22c5493b8b34ade2d118da4e
* Original Entrypoint: circuits/circuits/disclose/generated/vc_and_disclose_aadhaar_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/disclose/vc_and_disclose_aadhaar.circom
  - Function: VC_AND_DISCLOSE_Aadhaar
  - Line: 41-198
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-self-aadhaar-circuits.pdf
  - Bug ID: #02 - Missing Byte Range Checks Allows Packed Data Pollution
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`PackBytes` is used to pack the revealed data bytes. The template does not constrain each provided input value to be a byte, i.e. in the range [0, 2^8). This allows crafting inputs exceeding 255.

#### Proposed Mitigation

Add an explicit range check using `Num2Bits(8)`, ensuring `minimumAge` is constrained to a byte


## circom/selfxyz/self/zksecurity_missing_boolean_constraints_in_the_merkle_tree_path_leads_to_an_attacker_being_able_to_craft_a_fake_merkle_proof_for_an_arbitrary_leaf

### Missing boolean constraints in the Merkle tree path leads to an attacker being able to craft a fake Merkle proof for an arbitrary leaf

* Id: selfxyz/self/zksecurity_missing_boolean_constraints_in_the_merkle_tree_path_leads_to_an_attacker_being_able_to_craft_a_fake_merkle_proof_for_an_arbitrary_leaf
* Project: https://github.com/selfxyz/self
* Commit: 4f18c75041bb47c1862169eef82c22067642a83a
* Fix Commit: 8801c6c1d793896a778c4b597531bc710995d30c
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/4f18c75041bb47c1862169eef82c22067642a83a
* Original Entrypoint: circuits/circuits/register_id/instances/register_id_sha256_sha256_sha256_rsa_65537_4096.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/crypto/merkle-trees/smt.circom
  - Function: BinaryMerkleRoot
  - Line: 57-59
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-celo-self-audit-2.pdf
  - Bug ID: #02 - Missing boolean constraints in the Merkle tree path leads to an attacker being able to craft a fake Merkle proof for an arbitrary leaf
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `BinaryMerkleRoot` template is used in multiple places in the circuits to recover the root of a binary Merkle tree. Notice that this template does not enforce any boolean constraints on the `indices` array. As a result of this issue, an attacker can craft a fake Merkle proof for any leaf value of their choosing. Since the Merkle tree is used to perform multiple checks throughout the circuits, this means that the attacker can bypass any check that relies on a Merkle proof, for example the inclusion of the CSCA and DSC certificates in the certificates trees.

#### Proposed Mitigation

We recommend adding boolean constraints to the `indices` array in the `BinaryMerkleRoot` template.


## circom/selfxyz/self/zksecurity_an_attacker_can_craft_a_fake_non_inclusion_proof_for_a_given_key_due_to_an_aliasing_bug_in_the_smt_verifier

### An attacker can craft a fake non-inclusion proof for a given key due to an aliasing bug in the SMT verifier

* Id: selfxyz/self/zksecurity_an_attacker_can_craft_a_fake_non_inclusion_proof_for_a_given_key_due_to_an_aliasing_bug_in_the_smt_verifier
* Project: https://github.com/selfxyz/self
* Commit: 4f18c75041bb47c1862169eef82c22067642a83a
* Fix Commit: 99e8eece5e0867017ca076731fba63ed96ae4711
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/4f18c75041bb47c1862169eef82c22067642a83a
* Original Entrypoint: circuits/circuits/register_id/instances/register_id_sha256_sha256_sha256_rsa_65537_4096.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/crypto/merkle-trees/smt.circom
  - Function: SMTVerify
  - Line: 18-67
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-celo-self-audit-2.pdf
  - Bug ID: #00 - An attacker can craft a fake non-inclusion proof for a given key due to an aliasing bug in the SMT verifier
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `Num2Bits(254)` component presents an aliasing issue. The Num2Bits circuit in circomlib, witnesses the binary representation in the `out` array, and then checks that the recomposed value matches the input `in`. This computation is done modulo the field size, which is smaller than 2^254. Therefore, for approximately a quarter of the possible keys, an attacker can witness a different binary representation of the key.

#### Proposed Mitigation

We recommend replacing the `Num2Bits` component with `Num2Bits_strict`, which does not have the aliasing issue.


## circom/selfxyz/self/zksecurity_second_pre_image_attacks_on_packbytesandposeidon_may_be_used_to_register_arbitrary_passports_and_dsc_certificates

### Second Pre-Image Attacks On PackBytesAndPoseidon May Be Used To Register Arbitrary Passports And DSC Certificates

* Id: selfxyz/self/zksecurity_second_pre_image_attacks_on_packbytesandposeidon_may_be_used_to_register_arbitrary_passports_and_dsc_certificates
* Project: https://github.com/selfxyz/self
* Commit: 629dfdad1a867eb82ccba6857a545f3ef838e123
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/629dfdad1a867eb82ccba6857a545f3ef838e123
* Original Entrypoint: circuits/circuits/disclose/vc_and_disclose.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/passport/customHashers.circom
  - Function: PackBytesAndPoseidon
  - Line: 54-60
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-self-aadhaar-circuits.pdf
  - Bug ID: #01 - Second Pre-Image Attacks On PackBytesAndPoseidon May Be Used To Register Arbitrary Passports And DSC Certificates
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The function `PackBytesAndPoseidon(k)` in CustomHashers.circom is susceptible to a second pre-image attack: given an input x, an input y can be found such that `PackBytesAndPoseidon(k)(x) == PackBytesAndPoseidon(k)(y)` where y is not an array of bytes, but an array of arbitrary field elements. For example consider [0, 1, 0] and [256, 0, 0] they both compute [256] as an intermediate value (output of PackBytes bytes.circom). This intermediate value is later passed to the `CustomHasher` function: because the intermediate value is identical, both inputs will yield the same hash.

#### Proposed Mitigation

We recommend that the ranges of the bytes array are checked inside `PackBytesAndPoseidon`.


## circom/selfxyz/self/zksecurity_big_integer_zero_check_is_not_sound

### Big Integer Zero-Check Is Not Sound

* Id: selfxyz/self/zksecurity_big_integer_zero_check_is_not_sound
* Project: https://github.com/selfxyz/self
* Commit: 4f18c75041bb47c1862169eef82c22067642a83a
* Fix Commit: 
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/4f18c75041bb47c1862169eef82c22067642a83a
* Original Entrypoint: circuits/circuits/register_id/instances/register_id_sha256_sha256_sha256_rsa_65537_4096.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/crypto/bigInt/bigIntComparators.circom
  - Function: BigIntIsZero
  - Line: 05-26
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-celo-self-audit.pdf
  - Bug ID: #02 - Big Integer Zero-Check Is Not Sound
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

One of the core operation that is used throughout the big integer implementation is the assertion for a zero element. It is implemented in the template `BigIntIsZero` and is used in multiple places in the library. It does so by first accumulating the carries, then range checking the final carry value and then asserting that the final carry is the opposite of the most significant chunk. However, the accumulation of the carries is performed over the native field, so the entire relation is checked modulo the Circom native prime. This bug does not compromise completeness, as the zero integer will still be considered as zero modulo the native prime. However, this check is not sound, as a non-zero integer, which is zero mod native prime, will be considered zero by the library.

#### Proposed Mitigation

 It is recommended that the Big Integer Library used for ECDSA Verification is either carefully reviewed for such issues and fixed, or it is replaced by a more mature implementation.


## circom/selfxyz/self/zksecurity_the_registration_and_disclosure_circuits_lack_range_checks_for_the_input_indices

### The registration and disclosure circuits lack range checks for the input indices

* Id: selfxyz/self/zksecurity_the_registration_and_disclosure_circuits_lack_range_checks_for_the_input_indices
* Project: https://github.com/selfxyz/self
* Commit: 4f18c75041bb47c1862169eef82c22067642a83a
* Fix Commit: 49de54966e40709ac59d4070fd4bd0279b2a10c0
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/4f18c75041bb47c1862169eef82c22067642a83a
* Original Entrypoint: circuits/circuits/register_id/instances/register_id_sha256_sha256_sha256_rsa_65537_4096.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/register_id/register_id.circom
  - Function: REGISTER_ID
  - Line: 101-105
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-celo-self-audit-2.pdf
  - Bug ID: #03 - The registration and disclosure circuits lack range checks for the input indices
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

There are actually two separate issues with this code. (1) The computation `dsc_pubKey_offset + dsc_pubKey_actual_size` could overflow or underflow the field, leading to a wrong check semantics. (2) The `LessEqThan` template checks that the first input is less than or equal to the second input, but it assumes that both of the inputs are between 0 and 2^{12} - 1. If this is not the case, the circuit will produce some unexpected behaviour, as for example `LessEqThan(12)` with input values p - 1 and 0 will return 1 instead of 0. In this context, the intended range of the indices is to be between 0 and 2^{12} - 1, so this check could pass even if the indices are outside this range, leading to unexpected behaviour in the circuit.

#### Proposed Mitigation

We recommend to ensure that every computation done with indices does not overflow or underflow the field, by adding additional range checks. Additionally, we recommend to add range checks to the input signals of the `LessEqThan` template, to ensure that there is no unexpected behaviour when the inputs are outside the intended range.


## circom/selfxyz/self/zksecurity_forbidden_country_check_bypass_via_packed_byte_overflow

### Forbidden Country Check Bypass via Packed Byte Overflow

* Id: selfxyz/self/zksecurity_forbidden_country_check_bypass_via_packed_byte_overflow
* Project: https://github.com/selfxyz/self
* Commit: 3905a30aeb19016d22c5493b8b34ade2d118da4e
* Fix Commit: ['60501d17ee9b339e36c3a2a0d63f24bda65110a8', '4914074d11d1d6e4579c7fa4d20c0eae4fc1e02f']
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/3905a30aeb19016d22c5493b8b34ade2d118da4e
* Original Entrypoint: circuits/circuits/disclose/generated/vc_and_disclose_aadhaar_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/aadhaar/disclose/country_not_in_list.circom
  - Function: CountryNotInList
  - Line: 12-29
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-self-aadhaar-circuits.pdf
  - Bug ID: #00 - Forbidden Country Check Bypass via Packed Byte Overflow
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The elements of `forbidden_countries_list` are not range‑checked to be bytes, which means PackBytes allows for aliasing.

#### Proposed Mitigation

Add explicit byte range constraints, for example using `AssertBytes`, on every country code element before passing them to `PackBytes` in `CountryNotInList`.


## circom/selfxyz/self/zksecurity_exclusion_check_of_forbidden_countries_is_unsound_and_incomplete_due_to_incorrect_indexing

### Exclusion Check Of Forbidden Countries Is Unsound And Incomplete Due To Incorrect Indexing

* Id: selfxyz/self/zksecurity_exclusion_check_of_forbidden_countries_is_unsound_and_incomplete_due_to_incorrect_indexing
* Project: https://github.com/selfxyz/self
* Commit: 59c16d6e924c946970665504d883ced46981e5c1
* Fix Commit: 
* DSL: Circom
* Vulnerability: Computational Issues
* Impact: Soundness and Completeness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/selfxyz/self/59c16d6e924c946970665504d883ced46981e5c1
* Original Entrypoint: circuits/circuits/disclose/vc_and_disclose.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/circuits/utils/passport/disclose/proveCountryIsNotInList.circom
  - Function: ProveCountryIsNotInList
  - Line: 12-18
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-celo-self-audit.pdf
  - Bug ID: #00 - Exclusion Check Of Forbidden Countries Is Unsound And Incomplete Due To Incorrect Indexing
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `ProveCountryIsNotInList` check is performed by iterating over forbidden countries entry and comparing each letter individually for equality. However, the index `i` that is used to loop over the forbidden countries list is incorrect, as it should loop over `i * 3` instead.

#### Proposed Mitigation

Update the indexing of `forbidden_countries_list` to use `i*3`.


# Moonsong-Labs

## circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_non_determinism_of_some_inputs

### Non-Determinism of Some Inputs

* Id: Moonsong-Labs/zksync-social-login-circuit/openzeppelin_non_determinism_of_some_inputs
* Project: https://github.com/Moonsong-Labs/zksync-social-login-circuit
* Commit: 27cda6e74492fbad4aa3ca37ff5084ed391b534b
* Fix Commit: 5d02de9e550b6e671b732a432c590c02cb8bab3d
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/Moonsong-Labs/zksync-social-login-circuit/27cda6e74492fbad4aa3ca37ff5084ed391b534b
* Original Entrypoint: jwt-tx-validation.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: utils/fields.circom
  - Function: ExtractNonce / ExtractIssuer / ExtractAud / ExtractSub
  - Line: 19-124
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/openzeppelin-sso.pdf
  - Bug ID: Medium: Non-Determinism of Some Inputs
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Three related under-constrained input patterns were identified in `JwtTxValidation`. (1) The length inputs `nonceLength`, `issLength`, `audLength`, and `subLength` (consumed by `ExtractNonce`, `ExtractIssuer`, `ExtractAud`, and `ExtractSub` in `utils/fields.circom`) are not range-checked to fit in the bit width that their internal `LessThan` comparisons assume. A malicious prover can choose a value for `nonceLength` larger than the `LessThan` parameter `p-kp-k` so that `LessThan` returns the wrong bit, making `ExtractNonce` (via `RevealSubstring`) return a nonce with leading or trailing zeros. The same pattern applies to the other length signals. (2) The `nonce` bytes extracted from the JWT payload are assumed to be base64url-encoded but no constraint forces each byte into the base64url alphabet, so two distinct nonces (e.g. `abc-` and `abc+`) can decode to the same value, breaking determinism of the derived `nonce` sent to `VerifyNonce`. (3) In `VerifyNonce()` (utils/verify-nonce.circom:40-55) the decoded 32 bytes are packed into a single field via `packedNonce <== BytesToField(32).out = nonce[31] + 2**8 * nonce[30] + ... + 2**(8*31) * nonce[0]`, but the decoded byte array is not constrained to be below the BN254 prime, so values such as `nonce[0] = 255` can overflow the field and cause `packedNonce` to collide with a different byte sequence.

#### Proposed Mitigation

Range-check each length input with `Num2Bits` (so it fits in the bit width assumed by `LessThan`) before using it. Validate that `nonce` characters lie in the base64url alphabet (in particular reject `+` and `/`). Add an explicit `AssertFitsBinary`/range-check on the decoded nonce bytes so that `packedNonce` cannot overflow the field. The fix (PR #40, commit `5d02de9e`) adds a new `AssertFitsBinary` helper, validates the `nonce` against the base64url alphabet, and range-checks the lengths feeding `LessThan`.


## circom/Moonsong-Labs/zksync-social-login-circuit/openzeppelin_mismatched_base64url_decoding_may_break_completeness

### Mismatched Base64url Decoding May Break Completeness

* Id: Moonsong-Labs/zksync-social-login-circuit/openzeppelin_mismatched_base64url_decoding_may_break_completeness
* Project: https://github.com/Moonsong-Labs/zksync-social-login-circuit
* Commit: 27cda6e74492fbad4aa3ca37ff5084ed391b534b
* Fix Commit: 0548942278a414d85e2f3d406e171eeac325349e
* DSL: Circom
* Vulnerability: Over-Constrained
* Impact: Completeness
* Root Cause: Misimplementation of a Specification
* Reproduced: False
* Codebase: dataset/codebases/circom/Moonsong-Labs/zksync-social-login-circuit/27cda6e74492fbad4aa3ca37ff5084ed391b534b
* Original Entrypoint: jwt-tx-validation.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: utils/jwt-verify.circom
  - Function: JwtVerify
  - Line: 91-93
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/openzeppelin-sso.pdf
  - Bug ID: Medium: Mismatched Base64url Decoding May Break Completeness
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Per RFC-7519 the JWT payload is encoded with base64url (i.e., `-` and `_` instead of `+` and `/`), but `JwtVerify` decodes it with a plain base64 decoder: `b64Payload` (the URL-safe base64 bytes sliced out of `message`) is fed directly to `Base64Decode(maxPayloadLength)(b64Payload)` without first being converted from base64url to base64. The zkemail `Base64Decode` template only accepts the base64 alphabet, so any payload byte equal to `-` (45) or `_` (95) makes the constraints unsatisfiable — `reject such inputs` in the report's wording. While `VerifyNonce()` correctly calls `Base64UrlToBase64(maxNonceB64Length)(b64UrlNonce)` before `Base64Decode`, the main payload path skips this step, making it theoretically possible for a valid Google OIDC JWT containing `-` or `_` in its payload to be unverifiable by the circuit, breaking completeness.

#### Proposed Mitigation

Call `Base64UrlToBase64` on `b64Payload` before passing it to `Base64Decode`, matching how the nonce is handled. The fix in PR #40 (commit `0548942`) adds this conversion so that JWT payloads are correctly base64url-decoded.


# iden3

## circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryAdd

### Underconstrained points in MontgomeryAdd

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-004
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/montgomery.circom
  - Function: MontgomeryAdd
  - Line: 16-17
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-004: Underconstrained points in MontgomeryAdd
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Lambda calculation involves a division but there is no constraint on the divisor to be non-zero. In this case `out[1]` is underconstrained and can be set to any value.

#### Proposed Mitigation

Send `in2[0] - in1[0]` to `isZero` template and let the constraint there do the work.


## circom/iden3/circomlib/veridise_underconstrained_outputs_in_bitElementMulAny

### Underconstrained outputs in BitElementMulAny

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-006
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/escalarmulany.circom
  - Function: BitElementMulAny
  - Line: 21-22
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-006: Underconstrained outputs in BitElementMulAny
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`BitElementMulAny` template itself is fine, but it uses `MontgomeryDouble` and `MontgomeryAdd`, which have underconstraint bugs. With the same `input.json`, malicious prover can manipulate lambda value in `MontgomeryDouble` to let the circuit produce different outputs, making it nondeterministic.

#### Proposed Mitigation

Fix underconstraint bugs in `MontgomeryDouble` and `MontgomeryAdd`.


## circom/iden3/circomlib/veridise_underconstrained_points_in_montgomeryDouble

### Underconstrained points in MontgomeryDouble

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-005
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/montgomery.circom
  - Function: MontgomeryDouble
  - Line: 18-19
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-005: Underconstrained points in MontgomeryDouble
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Lambda calculation involves a division but there is no constraint on the divisor to be non-zero. In this case `lamda` is underconstrained and can be set to any value.

#### Proposed Mitigation

Send `in[1]` to `isZero` template and let the constraint there do the work.


## circom/iden3/circomlib/veridise_decoder_accepting_bogus_output_signal

### Decoder accepting bogus output signal

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-001
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/multiplexer.circom
  - Function: Decoder
  - Line: 10-11
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-001: Decoder accepting bogus output signal
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The circuit does not constrain `out` properly, malicious prover can set a bogus `out` and set `success` to 0, the circuit won't throw error. This makes integration error-prone.

#### Proposed Mitigation

Send `inp - i` to `isZero` template and let the constraint there do the work.


## circom/iden3/circomlib/veridise_underconstrained_outputs_in_windowmulfix

### Underconstrained outputs in WindowMulFix

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-008
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/escalarmulfix.circom
  - Function: WindowMulFix
  - Line: 70-131
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-008: Underconstrained outputs in WindowMulFix
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`WindowMulFix` template itself is fine, but it uses `MontgomeryDouble` and `MontgomeryAdd`, which have underconstraint bugs. With the same `input.json`, malicious prover can manipulate lambda value in `MontgomeryDouble` to let the circuit produce different outputs, making it nondeterministic.

#### Proposed Mitigation

Fix underconstraint bugs in `MontgomeryDouble` and `MontgomeryAdd`.


## circom/iden3/circomlib/veridise_underconstrained_outputs_in_window4

### Underconstrained outputs in Window4

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-007
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Unsafe Reuse of Circuit
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/pederson.circom
  - Function: Window4
  - Line: 47-108
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-007: Underconstrained outputs in Window4
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`Window4` template itself is fine, but it uses `MontgomeryDouble` and `MontgomeryAdd`, which have underconstraint bugs. With the same `input.json`, malicious prover can manipulate lambda value in `MontgomeryDouble` to let the circuit produce different outputs, making it nondeterministic.

#### Proposed Mitigation

Fix underconstraint bugs in `MontgomeryDouble` and `MontgomeryAdd`.


## circom/iden3/circomlib/veridise_underconstrained_points_in_edwards2Montgomery

### Underconstrained points in Edwards2Montgomery

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-002
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/montgomery.circom
  - Function: Edwards2Montgomery
  - Line: 7-8
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-002: Underconstrained points in Edwards2Montgomery
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The circuit does not implement constraint to avoid division by zero. When setting the divisor to 0, `out[1]` is underconstrained and can be set to any value.

#### Proposed Mitigation

Send `in[0]` and `1 - in[1]` to `isZero` template and let the constraint there do the work.


## circom/iden3/circomlib/kobi_gurkan_mimc_hash_assigned_but_not_constrained

### MiMC Hash: Assigned but not Constrained

* Id: iden3/circomlib/Kobi-Gurkan-MiMC-Hash-Assigned-but-not-Constrained
* Project: https://github.com/iden3/circomlib
* Commit: 324b8bf8cc4a80357354752deb6c2ae5be22e5f5
* Fix Commit: 109cdf40567fce284dca1d535819ce28922653e0
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Assigned but Unconstrained
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/324b8bf8cc4a80357354752deb6c2ae5be22e5f5
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/mimcsponge.circom
  - Function: MiMCSponge
  - Line: 28
* Source: Bug Tracker
  - Source Link: https://github.com/0xPARC/zk-bug-tracker?tab=readme-ov-file#14-mimc-hash-assigned-but-not-constrained
  - Bug ID: MiMC Hash: Assigned but not Constrained
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `MiMCSponge` template, `outs[0]` is assigned but not constrained, so it can be any value. Note that the circuit code is modified from a newer version since the original buggy code couldn't be reproduced in Circom version 2. The bug idea is still the same.

#### Proposed Mitigation

Use `<==` instead of `<--` to add a constraint to `outs[0]`.


## circom/iden3/circomlib/veridise_underconstrained_points_in_montgomery2Edwards

### Underconstrained points in Montgomery2Edwards

* Id: iden3/circomlib/veridise-V-CIRCOMLIB-VUL-003
* Project: https://github.com/iden3/circomlib
* Commit: cff5ab6288b55ef23602221694a6a38a0239dcc0
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circomlib/cff5ab6288b55ef23602221694a6a38a0239dcc0
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/montgomery.circom
  - Function: Montgomery2Edwards
  - Line: 7-8
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-circomlib.pdf
  - Bug ID: V-CIRCOMLIB-VUL-003: Underconstrained points in Montgomery2Edwards
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The circuit does not implement constraint to avoid division by zero. When setting the divisor to 0, `out[0]` is underconstrained and can be set to any value.

#### Proposed Mitigation

Send `in[1]` and `in[0] + 1` to `isZero` template and let the constraint there do the work.


## circom/iden3/circuits/trailofbits_unsafe_use_of_num2bits_in_multiple_circuits

### Unsafe use of Num2Bits in multiple circuits

* Id: iden3/circuits/trailofbits_unsafe_use_of_num2bits_in_multiple_circuits
* Project: https://github.com/iden3/circuits
* Commit: 7a1e04de3e5f3a9f0cfb27a43c9f41c986c1b9ed
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/iden3/circuits/7a1e04de3e5f3a9f0cfb27a43c9f41c986c1b9ed
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/lib/utils/claimUtils.circom
  - Function: Num2Bits
  - Line: 123
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/trailofbits-iden3-circuits.pdf
  - Bug ID: TOB-IDEN3-1
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Multiple circuits call `Num2Bits(254)` and `Num2Bits(256)` when working with field elements of the BN-254 prime field. These templates do not enforce uniqueness of the bit decompositions, allowing malicious provers to bypass token expiration or revocation.

#### Proposed Mitigation

Update the circuits to use `Num2Bits_strict()` instead of `Num2Bits(254)` or `Num2Bits(256)`.


# reclaimprotocol

## circom/reclaimprotocol/circom-chacha20/zksecurity_unsound_left_rotation

### Unsound Left Rotation

* Id: reclaimprotocol/circom-chacha20/zksecurity-1
* Project: https://github.com/reclaimprotocol/circom-chacha20
* Commit: ef9f5a5ad899d852740a26b30eabe5765673c71f
* Fix Commit: e5e756375fc1fc8dc48667b00cdf38c79a0fdf50
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/reclaimprotocol/circom-chacha20/ef9f5a5ad899d852740a26b30eabe5765673c71f
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/generics.circom
  - Function: RotateLeft32Bits
  - Line: 39-45
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-reclaimprotocol.pdf
  - Bug ID: #1 Unsound Left Rotation Gadget
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `part1` and `part2` signals are not sufficiently constrained. One can arbitrarily set a value to `part1` or `part2` and find a value for the other signal to satisfy the constraint on line 45. This way you can get another `out` value for a given `in`.

#### Proposed Mitigation

The recommendation to fix this issue was to constrain `part1` (resp. `part2`) to be (resp. ) bit-sized values. For the concrete mitigation applied, check the commit of the fix.


## circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_XOR_gadget

### Unsound XOR gadget

* Id: reclaimprotocol/circom-chacha20/zksecurity_Unsound_XOR_gadget
* Project: https://github.com/reclaimprotocol/circom-chacha20
* Commit: ef9f5a5ad899d852740a26b30eabe5765673c71f
* Fix Commit: ef9f5a5ad899d852740a26b30eabe5765673c71f
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/reclaimprotocol/circom-chacha20/ef9f5a5ad899d852740a26b30eabe5765673c71f
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: generics.circom
  - Function: XorBits
  - Line: 19-28
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-reclaimprotocol.pdf
  - Bug ID: Unsound XOR gadget
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Clean: ``
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `XorBits(M)`, the bit decomposition uses witness assignments `a_bits[i] <-- (a >> i) & 1` and `b_bits[i] <-- (b >> i) & 1` but the boolean constraints `a_bits[i] * (a_bits[i] - 1) === 0` and `b_bits[i] * (b_bits[i] - 1) === 0` are commented out. Without these constraints, `a_bits[i]` and `b_bits[i]` can be set to arbitrary field values (not just 0 or 1). The XOR computation `xor_bits[i] <== a_bits[i] + b_bits[i] - 2 * a_bits[i] * b_bits[i]` then operates on unconstrained inputs, allowing a malicious prover to produce arbitrary XOR outputs.

#### Proposed Mitigation

Uncomment the boolean constraints (`a_bits[i] * (a_bits[i] - 1) === 0` and same for `b_bits[i]`) to enforce that each bit is 0 or 1. Additionally constrain that the bit decomposition reconstructs the original values: `sum_a === a` and `sum_b === b`.


## circom/reclaimprotocol/circom-chacha20/zksecurity_Unsound_Addition_Gadget

### Unsound Addition Gadget

* Id: reclaimprotocol/circom-chacha20/zksecurity_Unsound_Addition_Gadget
* Project: https://github.com/reclaimprotocol/circom-chacha20
* Commit: ef9f5a5ad899d852740a26b30eabe5765673c71f
* Fix Commit: 4551ca64c9fe536b7b9b7498a1feb1ecdc847474
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/reclaimprotocol/circom-chacha20/ef9f5a5ad899d852740a26b30eabe5765673c71f
* Original Entrypoint: (same as direct)
* Direct Entrypoint: circuit.circom
* Location
  - Path: generics.circom
  - Function: Add32Bits
  - Line: 12-16
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-reclaimprotocol.pdf
  - Bug ID: Unsound Addition Gadget
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: ``
  - Compile and Preprocess: ``
  - Positive Test: ``
  - Clean: ``
  - Compile: `./zkbugs_compile.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

In `Add32Bits`, the carry bit `tmp` is assigned via witness `tmp <-- (a + b) >> 32` but never constrained. The output is computed as `out <== a + b - tmp * (1 << 32)`, which only enforces `out = a + b - tmp * 2^32` without verifying `tmp` is correct. A malicious prover can: (1) set `tmp = 0` when `a + b` overflows, producing a 33-bit output, or (2) set `tmp = 1` when `a + b` does not overflow, causing underflow to a value near the field prime. Both scenarios break the 32-bit wrapping invariant that callers depend on.

#### Proposed Mitigation

Constrain `tmp` to be a boolean (`tmp * (tmp - 1) === 0`) and verify the output is in range (`out < 2^32`), or use `Num2Bits(32)` on the output. Additionally, document that callers must ensure inputs are 32-bit values.


# Arianee

## circom/Arianee/arianee-sdk/veridise_ownershipproofs_could_identify_issuers

### OwnershipProofs could identify issuers

* Id: Arianee/arianee-sdk/veridise_ownershipproofs_could_identify_issuers
* Project: https://github.com/Arianee/arianee-sdk
* Commit: b7da01e0c81b9cccdc257040997c3500eb59db4f
* Fix Commit: 
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/Arianee/arianee-sdk/b7da01e0c81b9cccdc257040997c3500eb59db4f
* Original Entrypoint: packages/privacy-circuits/src/circom/ownershipVerifier/generated/ownershipVerifier_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/privacy-circuits/src/circom/ownershipVerifier/ownershipVerifier.circom
  - Function: OwnershipVerifier
  - Line: 1-29
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-arianee.pdf
  - Bug ID: V-ARIA-VUL-002: OwnershipProofs could identify issuers
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `OwnershipVerifier` template computes `commitmentHasher = Poseidon(3)` over `sig[0]`, `sig[1]`, `sig[2]` and constrains `commitmentHasher.out === pubCommitmentHash`. The three `sig` signals are intended to be an issuer's (R, S, V) ECDSA signature that is kept static per issuer, and the `tokenId` is never fed into the hash. Nothing in the circuit or in `ArianeeIssuerProxy.tryRegisterCommitment` forces different tokens to use different commitments, so a private issuer can re-use the same `pubCommitmentHash` across many tokens. Because commitments are effectively per-issuer identifiers, as soon as any single token is linked to an issuer, all other tokens sharing the same commitment are linked too, leaking the full set of assets and activity controlled by that issuer. The recommended fix binds `tokenId` (and any other per-token data) into the commitment, e.g. `commitmentHasher = Poseidon(4)` with `inputs[3] <== tokenId`.

#### Proposed Mitigation

Include per-token information in the commitment hash so that commitments cannot be reused across tokens. Concretely, extend the circuit to `Poseidon(4)` with `tokenId` as the fourth input, add `tokenId` as a public input, and verify it against the token being operated on in `ArianeeIssuerProxy`.


## circom/Arianee/arianee-sdk/veridise_creditnoteproofs_can_be_stolen

### CreditNoteProofs can be stolen

* Id: Arianee/arianee-sdk/veridise_creditnoteproofs_can_be_stolen
* Project: https://github.com/Arianee/arianee-sdk
* Commit: b7da01e0c81b9cccdc257040997c3500eb59db4f
* Fix Commit: 095a366101c50ba46601402805c0935650558aab
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/Arianee/arianee-sdk/b7da01e0c81b9cccdc257040997c3500eb59db4f
* Original Entrypoint: packages/privacy-circuits/src/circom/creditVerifier/generated/creditVerifier_main.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/privacy-circuits/src/circom/creditVerifier/creditVerifier.circom
  - Function: CreditVerifier
  - Line: 1-81
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/veridise-arianee.pdf
  - Bug ID: V-ARIA-VUL-001: CreditNoteProofs can be stolen
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `CreditVerifier` template proves knowledge of a `CreditNoteProof` by showing that a commitment `H(nullifier, secret, pubCreditType)` is in the credit Merkle tree and revealing a matching `pubNullifierHash`. The circuit has no binding to the spender or to a specific spend intent: it only exposes `pubRoot`, `pubCreditType`, and `pubNullifierHash` as public inputs. Because the on-chain `_verifyProof` function in `ArianeeIssuerProxy.sol` accepts the `CreditNoteProof` as a transaction argument without checking it against the transaction sender or an intent hash, anyone observing a valid proof in the mempool can front-run the legitimate spend by submitting the same `CreditNoteProof` themselves, burning the same nullifier and stealing the credit. The fix requires binding the proof to a spender-controlled value such as a `pubIntentHash` signal inside `CreditVerifier`, analogous to the `pubIntentHash` already present in `ownershipVerifier.circom`, so that the proof can only be spent by the intended caller.

#### Proposed Mitigation

Add a `pubIntentHash` (or equivalent spender-bound) public input to the `CreditVerifier` template and pass the caller's intent from `ArianeeIssuerProxy` through to `ArianeeCreditNotePool` so that the verifier re-checks it. Alternatively, fold `CreditVerifier` into the `OwnershipVerifier` as a single proof whose `pubIntentHash` binds the credit spend to a specific call, preventing front-runners from replaying the proof.


# rarimo

## circom/rarimo/passport-zk-circuits/koukyosyumei_under_constrained_date_encoder

### Under-constrained DateEncoder remainder signals

* Id: rarimo/passport-zk-circuits/koukyosyumei_under_constrained_date_encoder
* Project: https://github.com/rarimo/passport-zk-circuits
* Commit: 9143bc77eb2bdbd174eaa61b25b11adb5ee99f61
* Fix Commit: bbbe14c71c08be20a55f29bb2159261f0b32be0f
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/rarimo/passport-zk-circuits/9143bc77eb2bdbd174eaa61b25b11adb5ee99f61
* Original Entrypoint: circuits/identityManagement/queryIdentity.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: circuits/dateUtilities/dateEncoder.circom
  - Function: DateEncoder
  - Line: 10-23
* Source: GitHub Issue
  - Source Link: https://github.com/rarimo/passport-zk-circuits/pull/60
  - Bug ID: #60: Under-constrained DateEncoder remainder signals
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`DateEncoder` decomposes each of `day`, `month`, and `year` into a decimals digit and a rest digit using witness-only assignments (`<--`) followed by a single algebraic constraint of the form `dayDecimals * 10 + dayRest === day`. Because `dayRest`, `monthRest`, and `yearRest` are never range-checked to lie in `[0, 10)`, a malicious prover can satisfy the single constraint with other pairs. For instance, when `day = 4`, the honest assignment is `{dayDecimals: 0, dayRest: 4}`, but `{dayDecimals: 1, dayRest: -6}` (where `-6` is represented as `p - 6` in the BN254 scalar field) also satisfies `dayDecimals * 10 + dayRest === day`. The output `encoded` therefore takes on spurious values, so the UTF-8 `YYMMDD` encoding produced for downstream use is under-determined. The same pattern applies to the `monthRest` and `yearRest` signals assigned with `<--` on lines 16 and 20.

#### Proposed Mitigation

Constrain each rest signal to be a small non-negative integer less than 10. The fix PR (#60) introduces a `Num2Bits(4)` range check and a `LessThan(4)` comparison against `10` for each of `dayRest`, `monthRest`, and `yearRest`, asserting `ltDay.out === 1` so that only canonical decompositions satisfy the circuit.


# zkemail

## circom/zkemail/zk-email-verify/matterlabs_underconstrained_fpmul_circuit

### Underconstrained FpMul circuit

* Id: zkemail/zk-email-verify/matterlabs_underconstrained_fpmul_circuit
* Project: https://github.com/zkemail/zk-email-verify
* Commit: fc9949763858ca363a73a2764d9c1d26ef227478
* Fix Commit: 9ed3769dc3d96fb0d7c45f1f014dcd9bfb63675b
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/zkemail/zk-email-verify/fc9949763858ca363a73a2764d9c1d26ef227478
* Original Entrypoint: packages/circuits/tests/test-circuits/rsa-test.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circuits/lib/fp.circom
  - Function: FpMul
  - Line: 16-76
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/matterlabs-zkemail.pdf
  - Bug ID: #9 Underconstrained FpMul circuit
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `FpMul(n, k)` template in `packages/circuits/lib/fp.circom` computes `a * b mod p` by invoking `long_div(n, k, k, ab_proper, p)` and assigning the returned quotient and remainder using the unconstrained `<--` operator: `q[i] <-- long_div_out[0][i]` and `r[i] <-- long_div_out[1][i]`. Each chunk is then range-checked to `n` bits via `Num2Bits(n)`, but the template never constrains the remainder to satisfy `r < p`. A malicious prover can therefore choose `q` and `r` values that still pass the `n`-bit range checks while violating the modular invariant `r < p`. The report demonstrates this with `FpMul(256, 2)` on inputs `A=(4,0), B=(4,0), P=(5,0)`: setting `Q=(0,0)` and `R=(16,0)` makes the circuit output `(16,0)` instead of the expected `(1,0)`, even though `16 >= 5 = P`. `FpMul` is used by `RSAVerifier65537` to compute `signature^65537 mod pubkey_modulus`, so the missing `R < P` check weakens a core step of DKIM signature verification.

#### Proposed Mitigation

Add a `BigLessThan(n, k)` gadget that constrains the remainder `r` to be strictly less than the modulus `p`, and enforce `r_p_lt_check.out === 1`. The fix commit `9ed3769d` introduces exactly this check inside `FpMul`.


## circom/zkemail/zk-email-verify/zksecurity_sha256_templates_return_zero_on_arbitrary_inputs

### SHA256 templates can be made return 0 on arbitrary inputs

* Id: zkemail/zk-email-verify/zksecurity_sha256_templates_return_zero_on_arbitrary_inputs
* Project: https://github.com/zkemail/zk-email-verify
* Commit: f2fb77c6ab49f4e85c424c3334ce69c018648fa7
* Fix Commit: ad0ad6
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Missing Input Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/zkemail/zk-email-verify/f2fb77c6ab49f4e85c424c3334ce69c018648fa7
* Original Entrypoint: packages/circuits/tests/test-circuits/sha-test.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circuits/lib/sha.circom
  - Function: Sha256General
  - Line: 
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/zksecurity-zkemail.pdf
  - Bug ID: #02
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

Both custom SHA256 templates `Sha256General` and `Sha256Partial`, as well as their bytes variants `Sha256Bytes` and `Sha256BytesPartial`, are vulnerable to an attack where the prover passes a maliciously crafted `paddedInLength` which causes the returned hash result to be the all-zeros bit array. The signal `inBlockIndex` is computed via `inBlockIndex <-- (paddedInLength >> 9)` and constrained by `paddedInLength === inBlockIndex * 512`. The `ItemAtIndex` template used to select the final hash chunk does not properly constrain `index` to lie within the array bounds — it uses `LessThan(bitLength)` but small negative values modulo the field size (like `-5`, ..., `-1`, `0`) pass the `LessThan` check. By setting `inBlockIndex - 1` to a large number close to the native modulus (exceeding `maxBlocks`), the `ItemAtIndex` output defaults to zero for all out-of-bounds indices, producing an all-zeros hash regardless of input.

#### Proposed Mitigation

In `ItemAtIndex`, remove `LessThan` and instead add an assertion that the sum of all `eqs[i]` equals 1, proving the index selects exactly one array element. In all SHA256 templates, document that `paddedInLength` is constrained to fit in `ceil(log2(maxBitLength))` bits (for `Sha256General`/`Sha256Partial`) or `ceil(log2(8 * maxByteLength))` bits (for `Sha256Bytes`/`Sha256BytesPartial`). In `EmailVerifier`, use `Num2Bits` to constrain `emailHeaderLength` and `emailBodyLength` to appropriate bit lengths.


## circom/zkemail/zk-regex/matterlabs_fromaddrregex_allows_email_address_spoofing

### FromAddrRegex circuit allows for email address spoofing

* Id: zkemail/zk-regex/matterlabs_fromaddrregex_allows_email_address_spoofing
* Project: https://github.com/zkemail/zk-regex
* Commit: 531575345558ba938675d725bd54df45c866ef74
* Fix Commit: 7002a2179e076449b84e3e7e8ba94e88d0a2dc2f
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Wrong Translation of Logic into Constraints
* Reproduced: False
* Codebase: dataset/codebases/circom/zkemail/zk-regex/531575345558ba938675d725bd54df45c866ef74
* Original Entrypoint: packages/circom/tests/circuits/test_from_addr_regex.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circom/circuits/common/from_all_regex.circom
  - Function: FromAllRegex
  - Line: 6-110
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/matterlabs-zkemail.pdf
  - Bug ID: #2 FromAddrRegex circuit allows for email address spoofing
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The zk-regex compiler emits an unsound Circom circuit for any regular expression of the form `(\r\n|^)Prefix:...`, a family that includes `FromAllRegex` (pattern `(\r\n|^)from:[^\r\n]+\r\n`), `ToAllRegex`, `SubjectAllRegex`, and others used throughout ether-email-auth. To encode `^` the compiler prepends a sentinel byte 255 (0xff) to the input (`in[0] <== 255;`) and treats value 255 in any position as a DFA reset to state 0. A prover can therefore place a raw `\xff` byte earlier in the header — for example in the `Subject:` header, which Gmail and other providers accept as valid payload — and have the DFA restart right before a spoofed `from:` line. The regex accepts the spoofed address as the matched From value even though the DKIM-signed header is unchanged. The `FromAllRegex` circuit is the common subroutine behind `FromAddrRegex`, which ether-email-auth uses in both `EmailAuth` and `EmailAuthWithBodyParsing` to extract the sender, so the flaw allows crafting a valid DKIM-signed email while attributing it to an attacker-chosen address.

#### Proposed Mitigation

Fix the zk-regex compiler to either reject 255 in the input signal or rework the `^` encoding so it no longer relies on a reserved sentinel. The recommended patch is to add an explicit constraint forbidding 255 from appearing in `msg[]` (e.g. `IsZero(msg[i] - 255).out === 0`), then regenerate every common/*_regex.circom from the fixed compiler.


## circom/zkemail/zk-regex/matterlabs_email_spoofing_via_manipulated_from_header

### Email spoofing via manipulated From header

* Id: zkemail/zk-regex/matterlabs_email_spoofing_via_manipulated_from_header
* Project: https://github.com/zkemail/zk-regex
* Commit: 531575345558ba938675d725bd54df45c866ef74
* Fix Commit: 7002a2179e076449b84e3e7e8ba94e88d0a2dc2f
* DSL: Circom
* Vulnerability: Under-Constrained
* Impact: Soundness
* Root Cause: Misimplementation of a Specification
* Reproduced: False
* Codebase: dataset/codebases/circom/zkemail/zk-regex/531575345558ba938675d725bd54df45c866ef74
* Original Entrypoint: packages/circom/tests/circuits/test_from_addr_regex.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circom/circuits/common/email_addr_with_name_regex.circom
  - Function: EmailAddrWithNameRegex
  - Line: 6-190
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/matterlabs-zkemail.pdf
  - Bug ID: #1 Email spoofing via manipulated From header
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

The `EmailAddrWithNameRegex` circuit is the subroutine `FromAddrRegex` uses to parse `From: Some Name <user@domain>` style headers. Its pattern `[^\r\n]+<[A-Za-z0-9!#$%&'*+=?\-\^_\`{|}~./@]+@[a-zA-Z0-9.\-]+>` is too permissive: the `[^\r\n]+` prefix greedily swallows arbitrary bytes, and the regex accepts any `<local@domain>` segment that eventually appears in the line. Outlook.com and Mail.ru accept SMTP submissions whose `From:` header embeds a quoted nickname containing a second `<...>` pair, for example `from: "Some name <victim@any-domain>" < attacker@outlook.com>` or `from:Some name <victim@any-domain> <attacker@mail.ru >`. The real sender (used for DKIM) is `attacker@outlook.com` / `attacker@mail.ru`, but the regex `reveal0` output in `FromAddrRegex` exposes `victim@any-domain`, attributing the DKIM-signed message to the spoofed address. Because ZK Email treats the extracted address as the root of trust, this breaks the project's entire security model.

#### Proposed Mitigation

Reimplement `EmailAddrWithNameRegex` so the prefix does not consume arbitrary printable bytes — e.g. restrict the name part to RFC 5322-compliant display-name characters, disallow embedded `<`/`>` inside quoted strings, and anchor the match at the line start. The report notes that tightening the existing regex alone is unlikely to be sufficient given SMTP parser divergence, and recommends a full rewrite.


## circom/zkemail/ether-email-auth/matterlabs_emailauth_fails_with_overlapping_invitation_code_regex

### EmailAuth circuit doesn't work with specific email addresses and domain names

* Id: zkemail/ether-email-auth/matterlabs_emailauth_fails_with_overlapping_invitation_code_regex
* Project: https://github.com/zkemail/ether-email-auth
* Commit: 8a62db1e676aedbb20a403be95fffebef12b97e4
* Fix Commit: 984b5919a9be715b743b08863ab6471c2b5356a6
* DSL: Circom
* Vulnerability: Over-Constrained
* Impact: Completeness
* Root Cause: Circuit Design Issue
* Reproduced: False
* Codebase: dataset/codebases/circom/zkemail/ether-email-auth/8a62db1e676aedbb20a403be95fffebef12b97e4
* Original Entrypoint: packages/circuits/src/email_auth.circom
* Direct Entrypoint: circuit.circom
* Location
  - Path: packages/circuits/src/email_auth_template.circom
  - Function: EmailAuth
  - Line: 119-141
* Source: Audit Report
  - Source Link: https://github.com/zksecurity/zkbugs/blob/main/reports/documents/matterlabs-zkemail.pdf
  - Bug ID: #7 EmailAuth circuit doesn't work with specific email addresses and domain names
* Input
  - Original: input.json
  - Direct: direct_input.json
* Commands
  - Setup Environment: `./zkbugs_setup.sh`
  - Compile: `./zkbugs_compile.sh`
  - Compile and Preprocess: `./zkbugs_compile_setup.sh`
  - Positive Test: `./zkbugs_positive_test.sh`
  - Clean: `./zkbugs_clean.sh`

#### Running

Scripts support two modes controlled by the `ZKBUGS_MODE` environment variable:

- **`original`** (default): compiles the project's main circuit from the full codebase.
- **`direct`**: compiles an isolated wrapper (`circuit.circom`) that only instantiates the vulnerable template.

```bash
### Setup (run once)
./zkbugs_setup.sh

### Compile only (no zkey ceremony)
./zkbugs_compile.sh                        # original mode
ZKBUGS_MODE=direct ./zkbugs_compile.sh     # direct mode

### Full setup with zkey ceremony + positive test (direct mode)
ZKBUGS_MODE=direct ./zkbugs_compile_setup.sh
ZKBUGS_MODE=direct ./zkbugs_positive_test.sh

### Clean build artifacts
./zkbugs_clean.sh
```

#### Short Description of the Vulnerability

`EmailAuth` instantiates two regex templates over the same subject string: `InvitationCodeWithPrefixRegex` with pattern `( )?(c|C)ode( )?(0|1|2|3|4|5|6|7|8|9|a|b|c|d|e|f)+` and `EmailAddrRegex` for email address extraction. It then computes `masked_subject_bytes[i] <== subject_all[i] - removed_code[i] - removed_subject_email_addr[i]`, assuming the two matched substrings never overlap. This assumption breaks for legitimate commands such as `Send 0.1 ETH to donate@codef.be`, where the domain `codef.be` contains the substring `code` followed by hex characters, so `InvitationCodeWithPrefixRegex` accepts `code`,`f`,`.`,`b`,`e` as an invitation code while `EmailAddrRegex` simultaneously matches `donate@codef.be`. The overlapping bytes are subtracted twice, producing negative field values in `masked_subject_bytes`, so `Bytes2Ints(max_subject_bytes)(masked_subject_bytes)` cannot produce a valid witness — the prover cannot generate a proof for the well-formed command and the wallet feature becomes unusable for such emails/domains. The direct wrapper shows `InvitationCodeWithPrefixRegex(32)("Send 0.1 ETH to donate@codef.be\0")` returning `out == 1`, confirming the spurious match that is the root of the completeness failure.

#### Proposed Mitigation

Tighten the `InvitationCodeWithPrefixRegex` pattern so it does not match substrings inside email addresses or other free-text — for example by anchoring on a trailing whitespace/end-of-subject boundary, or by excluding invitation-code matches whose character range overlaps the `EmailAddrRegex` match inside `EmailAuth`. The fix commit `984b5919` replaces the subject regex scheme entirely.