XRPLF/rippled

Follow-up from a review comment on #7012: #7012 (comment) In include/xrpl/basics/FileUtilities.h, TempDir::path() and TempDir::file() both return std::string: [[nodiscard]] std::string path() const; [[nodiscard]] std::string file(std::string const& name) const; Now that the codebase uses std::filesystem (#7012), these should probably return std::filesystem::path instead, so callers don't have to round-trip through strings. file() could likewise take a std::filesystem::path const& parameter. This was intentionally left as-is in #7012 to keep that PR focused on the boost::filesystem → std::filesystem swap. Work Change the return types (and file()'s parameter type) to std::filesystem::path. Update call sites, which are mostly in tests/benchmarks.

Missing input type check for vault_id and owner causes exception on non-scalar JSON types Severity: LOW parseVault checks isMember() for vault_id and owner, then immediately calls asString() without verifying the JSON value is a string (or at least a scalar). If vault_id or owner is a JSON object, array, or null, asString() throws Json::LogicError. While the RPC framework catches std::exception, the result is a generic internal error instead of a proper invalidParams error. Root cause: No isString() check before asString() calls at lines 23 and 32. src/xrpld/rpc/handlers/VaultInfo.cpp:23 if (!uNodeIndex.parseHex(params[jss::vault_id].asString())) src/xrpld/rpc/handlers/VaultInfo.cpp:32 auto const id = parseBase58<AccountID>(params[jss::owner].asString()); Exploit scenario: 1. Client sends {"method": "vault_info", "params": [{"vault_id": {"nested": "object"}}]}. 2. params[jss::vault_id].asString() throws Json::LogicError. 3. Exception propagates to the RPC dispatch framework. 4. Client

transaction_entry uses non-standard ad-hoc error strings Severity: LOW The doTransactionEntry handler sets error responses using ad-hoc string values directly on jss::error (e.g., "fieldNotFoundTransaction", "notYetImplemented", "malformedRequest", "transactionNotFound") instead of using the standard rpcError() or RPC::make_error() functions with registered error codes. These non-standard error strings are not documented in the error code enumeration and cannot be reliably parsed by client libraries that expect standard RPC error codes. Additionally, these responses lack the error_code numeric field and error_message field that standard errors include. Root cause: Legacy code that predates the standardized error handling framework. The XXX comments in the source (lines 16, 35, 42) indicate this code was known to need cleanup. src/xrpld/rpc/handlers/transaction/TransactionEntry.cpp:27-47 if (!context.params.isMember(jss::tx_hash)) { jvResult[jss::error] = "fieldNotFoundTransaction";

Missing type validation on public_key parameter in manifest handler Severity: LOW In doManifest, params[jss::public_key].asString() is called without first checking that the parameter is a string type. If a client sends {"public_key": 12345} or {"public_key": []}, jsoncpp's asString() will throw for non-convertible types, resulting in an unhelpful rpcINTERNAL error via the generic exception handler. Root cause: No type check before params[jss::public_key].asString() on line 20 of Manifest.cpp. src/xrpld/rpc/handlers/server_info/Manifest.cpp:17-20 if (!params.isMember(jss::public_key)) return RPC::missing_field_error(jss::public_key); auto const requested = params[jss::public_key].asString(); Exploit scenario: 1. User sends {"method": "manifest", "params": [{"public_key": [1,2,3]}]}. 2. asString() throws on the array value. 3. User receives rpcINTERNAL instead of a proper invalidParams error. Invariant gap: The exception is caught by callMethod's generic catch block, so no crash, b

Missing type validation on counters parameter causes unhandled exception path Severity: LOW In doServerInfo and doServerState, context.params[jss::counters].asBool() is called without first validating that the counters parameter is a boolean or numeric type. If a client sends {"counters": "true"} or {"counters": []}, jsoncpp's asBool() throws a Json::LogicError. The exception is caught by the generic handler in callMethod which returns rpcINTERNAL, but this is a confusing error message that doesn't indicate the actual problem. Root cause: No type check before calling asBool() on line 19 of ServerInfo.cpp and line 18 of ServerState.cpp. src/xrpld/rpc/handlers/server_info/ServerInfo.cpp:19 context.params.isMember(jss::counters) && context.params[jss::counters].asBool() src/xrpld/rpc/handlers/server_info/ServerState.cpp:18 context.params.isMember(jss::counters) && context.params[jss::counters].asBool() Exploit scenario: 1. User sends {"method": "server_info", "params": [{"counters": "yes"