EMSA-PKCS1-v1_5 (RFC 8017 §9.2) builds 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo, with at least eight 0xFF bytes, where DigestInfo is the DER encoding of the hash algorithm and the hash. For SHA-256 the DigestInfo prefix is 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. There is no randomness, so the same key and message always give the same signature.
Where it is used: JOSE RS256, RS384 and RS512 (RFC 7518 §3.3); X.509 sha256WithRSAEncryption (1.2.840.113549.1.1.11); TLS 1.2 signatures; DKIM rsa-sha256; SSH rsa-sha2-256 and rsa-sha2-512. TLS 1.3 allows it only for signatures inside certificates (rsa_pkcs1_sha256, 0x0401); handshake signatures must use PSS.
The known pitfall is in verifiers, not in the scheme: parsers that did not check that the DigestInfo fills the rest of the block allowed Bleichenbacher's 2006 forgery for public exponent 3. RFC 8017 §8.2.2 recommends re-encoding the expected block and comparing, and FIPS 186-5 §5.4(h) spells out the required checks. Do not confuse this signature padding with PKCS #1 v1.5 encryption padding (the padding-oracle problem) or with the PKCS #1 private key file format.