程式碼品質不佳，會導致無法預料的行為。從使用者的角度來看，這通常表現為可用性不佳。對於攻擊者而言，這提供了以意想不到的方式向系統施加壓力的機會。
PendingIntent 的旗標值設為 FLAG_MUTABLE。建立的 Pending Intent 具有 FLAG_MUTABLE 旗標值時，很容易受到下游設定的未指定 Intent 欄位的影響，這可能會修改 Intent 的能力並使系統容易受到攻擊。PendingIntent 後修改其底層 Intent，可能會使系統容易受到攻擊。這主要取決於底層 Intent 的整體能力。在大多數情況下，最佳方式是將 PendingIntent 旗標設為 FLAG_IMMUTABLE 來防止潛在問題。FLAG_MUTABLE 旗標值建立 PendingIntent。
...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
read() 時未能回傳預期的位元組數：
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
CALL "CBL_ALLOC_MEM"
USING mem-pointer
BY VALUE mem-size
BY VALUE flags
RETURNING status-code
END-CALL
IF status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
SET ADDRESS OF mem TO mem-pointer
END-IF
PERFORM write-data
IF ws-status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
DISPLAY "Success!"
END-IF
CALL "CBL_FREE_MEM"
USING BY VALUE mem-pointer
RETURNING status-code
END-CALL
GOBACK
.
dealloc() 方法中釋放記憶體。init() 方法中分配了記憶體，但無法在 deallocate() 方法中將其釋放，導致記憶體洩露：
- (void)init
{
myVar = [NSString alloc] init];
...
}
- (void)dealloc
{
[otherVar release];
}
realloc() 調整原始分配大小失敗時，洩露了分配記憶體區塊。
char* getBlocks(int fd) {
int amt;
int request = BLOCK_SIZE;
char* buf = (char*) malloc(BLOCK_SIZE + 1);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
while ((amt % BLOCK_SIZE) != 0) {
if (amt < request) {
goto ERR;
}
request = request + BLOCK_SIZE;
buf = realloc(buf, request);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
}
return buf;
ERR:
if (buf) {
free(buf);
}
return NULL;
}
realloc() 的呼叫未能調整原始配置的大小，則以下 Micro Focus COBOL 程式就會洩漏配置的記憶體區塊。
CALL "malloc" USING
BY VALUE mem-size
RETURNING mem-pointer
END-CALL
ADD 1000 TO mem-size
CALL "realloc" USING
BY VALUE mem-pointer
BY VALUE mem-size
RETURNING mem-pointer
END-CALL
IF mem-pointer <> null
CALL "free" USING
BY VALUE mem-pointer
END-CALL
END-IF
NullException。cmd」的屬性。如果攻擊者可以控制程式環境，使「cmd」變成未定義狀態，那麼程式會在嘗試呼叫 Trim() 方法時拋出一個 Null 指標異常。
string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
null 之前先解除參照可能為 null 的指標，將會造成「解除參照之後檢查」的錯誤。當程式執行明確的 null 檢查，但仍繼續解除參照已知為 null 的指標時，將會造成「檢查後解除參照」的錯誤。這種類型的錯誤通常是打字錯誤或程式設計師的疏忽所造成。當程式明確的將某指標設定為 null，卻在之後解除參考該指標，則會發生儲存後解除參照錯誤。這種錯誤通常是由於程式設計師在宣告變數時將變數初始化為 null 所致。ptr 不是 NULL。當程式設計師取消參照指標時，這個假設就變得清楚。當程式設計師檢查 ptr 為 NULL 時，這個假設其實就出現其矛盾之處。若在 if 指令中檢查 ptr 時，其可為 NULL，則解除參照時也可為 NULL，並產生分段錯誤。範例 2：在以下程式碼中，程式設計師確定變數
ptr->field = val;
...
if (ptr != NULL) {
...
}
ptr 是 NULL，並在之後以錯誤的方式解除參照。若在 if 陳述式中檢查 ptr 時，其非 NULL，就會發生 null 解除參照，從而導致分段錯誤。範例 3：在以下程式碼中，程式設計師忘記了字串
if (ptr == null) {
ptr->field = val;
...
}
'\0' 實際上是 0 還是 NULL，因此解除參照 Null 指標，並導致分段錯誤。範例 4：在以下程式碼中，程式設計師明確地將變數
if (ptr == '\0') {
*ptr = val;
...
}
ptr 設定為 NULL。之後，程式設計師先解除參照 ptr，再檢查物件是否為 null 值。
*ptr = NULL;
...
ptr->field = val;
...
}
NullPointerException。cmd」的屬性。如果攻擊者可以控制程式環境，使「cmd」變成未定義狀態，那麼程式會在嘗試呼叫 trim() 方法時拋出一個 Null 指標異常。
String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
SqlClientPermission 物件，其規定使用者可連接到資料庫的方式。在此範例中，程式把 false 作為第二個參數傳遞給構造函數，控制使用者是否可使用空白密碼進行連接。若傳送的參數值為 false，表示不允許密碼為空白。
...
SCP = new SqlClientPermission(pstate, false);
...
PermissionState 物件代替了所有傳遞至第二個參數的值，因此構造函數允許使用空白密碼進行資料庫連線，這與第二個引數互相矛盾。若要禁止使用空白密碼，程式應該把 PermissionState.None 傳遞給建構函數的第一個參數。因為其功能的不明確，SqlClientPermission 構造函數的雙參數版本已遭反對，改用單參數版本，單參數版本可提供與雙參數版本相同的功能，但是避免了誤譯的風險。getpw() 來檢驗一個純文字密碼是否與使用者加密密碼匹配。如果密碼是有效的，那函數將把 result 設為 1；如果無效，將其設為 0。
...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...
getpw() 函數會產生問題，因為這會導致傳遞至其第二個參數的緩衝區發生溢位。鑒於存在這一弱點，getpw() 已由 getpwuid() 取代，後者會執行與 getpw() 相同的查詢，但是會傳回指向靜態分配之結構的指標以降低風險。
...
String name = new String(nameBytes, highByte);
...
nameBytes 所呈現的字串而定。由於用於編碼字串的字元組的演變，所以不推薦使用此建構函式，取而代之的是新的構造函式。新的構造函式可接受作為名為 charset 的其中一個參數，用來編碼字元組以進行字元轉換。Digest::HMAC stdlib，但由於發行涉及意外，因此在文件中明確勸阻這樣的使用。
require 'digest/hmac'
hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...
Digest::HMAC 類別時便會立即捨棄。由於實驗性和未正確測試的程式碼造成此要求無法如預期般運作，強烈勸阻使用此類別，尤其考慮到加密式功能涉及的關係 HMAC。block.blockhash() 取得目前區塊的雜湊。
bytes32 blockhash = block.blockhash(0);
IsBadXXXPtr() 類別的原因很多。這些函數的特性如下：IsBadWritePtr() 以嘗試防止不良的記憶體寫入。
if (IsBadWritePtr(ptr, length))
{
[handle error]
}
public class Totaller {
private int total;
public int total() {
...
}
}
hardcap 是很難判斷的。
contract Tokensale {
uint hardcap = 10000 ether;
function Tokensale() { }
function fetchCap() public constant returns(uint) {
return hardcap;
}
}
contract Presale is Tokensale {
uint hardcap = 1000 ether;
function Presale() Tokensale() { }
}